xref: /netbsd-src/external/public-domain/sqlite/man/SQLITE_FCNTL_LOCKSTATE.3 (revision b9988867a8ad969c45a52aa7628bc932ec98d46b)
1.Dd January 24, 2024
2.Dt SQLITE_FCNTL_LOCKSTATE 3
3.Os
4.Sh NAME
5.Nm SQLITE_FCNTL_LOCKSTATE ,
6.Nm SQLITE_FCNTL_GET_LOCKPROXYFILE ,
7.Nm SQLITE_FCNTL_SET_LOCKPROXYFILE ,
8.Nm SQLITE_FCNTL_LAST_ERRNO ,
9.Nm SQLITE_FCNTL_SIZE_HINT ,
10.Nm SQLITE_FCNTL_CHUNK_SIZE ,
11.Nm SQLITE_FCNTL_FILE_POINTER ,
12.Nm SQLITE_FCNTL_SYNC_OMITTED ,
13.Nm SQLITE_FCNTL_WIN32_AV_RETRY ,
14.Nm SQLITE_FCNTL_PERSIST_WAL ,
15.Nm SQLITE_FCNTL_OVERWRITE ,
16.Nm SQLITE_FCNTL_VFSNAME ,
17.Nm SQLITE_FCNTL_POWERSAFE_OVERWRITE ,
18.Nm SQLITE_FCNTL_PRAGMA ,
19.Nm SQLITE_FCNTL_BUSYHANDLER ,
20.Nm SQLITE_FCNTL_TEMPFILENAME ,
21.Nm SQLITE_FCNTL_MMAP_SIZE ,
22.Nm SQLITE_FCNTL_TRACE ,
23.Nm SQLITE_FCNTL_HAS_MOVED ,
24.Nm SQLITE_FCNTL_SYNC ,
25.Nm SQLITE_FCNTL_COMMIT_PHASETWO ,
26.Nm SQLITE_FCNTL_WIN32_SET_HANDLE ,
27.Nm SQLITE_FCNTL_WAL_BLOCK ,
28.Nm SQLITE_FCNTL_ZIPVFS ,
29.Nm SQLITE_FCNTL_RBU ,
30.Nm SQLITE_FCNTL_VFS_POINTER ,
31.Nm SQLITE_FCNTL_JOURNAL_POINTER ,
32.Nm SQLITE_FCNTL_WIN32_GET_HANDLE ,
33.Nm SQLITE_FCNTL_PDB ,
34.Nm SQLITE_FCNTL_BEGIN_ATOMIC_WRITE ,
35.Nm SQLITE_FCNTL_COMMIT_ATOMIC_WRITE ,
36.Nm SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE ,
37.Nm SQLITE_FCNTL_LOCK_TIMEOUT ,
38.Nm SQLITE_FCNTL_DATA_VERSION ,
39.Nm SQLITE_FCNTL_SIZE_LIMIT ,
40.Nm SQLITE_FCNTL_CKPT_DONE ,
41.Nm SQLITE_FCNTL_RESERVE_BYTES ,
42.Nm SQLITE_FCNTL_CKPT_START ,
43.Nm SQLITE_FCNTL_EXTERNAL_READER ,
44.Nm SQLITE_FCNTL_CKSM_FILE ,
45.Nm SQLITE_FCNTL_RESET_CACHE
46.Nd standard file control opcodes
47.Sh SYNOPSIS
48.In sqlite3.h
49.Fd #define SQLITE_FCNTL_LOCKSTATE
50.Fd #define SQLITE_FCNTL_GET_LOCKPROXYFILE
51.Fd #define SQLITE_FCNTL_SET_LOCKPROXYFILE
52.Fd #define SQLITE_FCNTL_LAST_ERRNO
53.Fd #define SQLITE_FCNTL_SIZE_HINT
54.Fd #define SQLITE_FCNTL_CHUNK_SIZE
55.Fd #define SQLITE_FCNTL_FILE_POINTER
56.Fd #define SQLITE_FCNTL_SYNC_OMITTED
57.Fd #define SQLITE_FCNTL_WIN32_AV_RETRY
58.Fd #define SQLITE_FCNTL_PERSIST_WAL
59.Fd #define SQLITE_FCNTL_OVERWRITE
60.Fd #define SQLITE_FCNTL_VFSNAME
61.Fd #define SQLITE_FCNTL_POWERSAFE_OVERWRITE
62.Fd #define SQLITE_FCNTL_PRAGMA
63.Fd #define SQLITE_FCNTL_BUSYHANDLER
64.Fd #define SQLITE_FCNTL_TEMPFILENAME
65.Fd #define SQLITE_FCNTL_MMAP_SIZE
66.Fd #define SQLITE_FCNTL_TRACE
67.Fd #define SQLITE_FCNTL_HAS_MOVED
68.Fd #define SQLITE_FCNTL_SYNC
69.Fd #define SQLITE_FCNTL_COMMIT_PHASETWO
70.Fd #define SQLITE_FCNTL_WIN32_SET_HANDLE
71.Fd #define SQLITE_FCNTL_WAL_BLOCK
72.Fd #define SQLITE_FCNTL_ZIPVFS
73.Fd #define SQLITE_FCNTL_RBU
74.Fd #define SQLITE_FCNTL_VFS_POINTER
75.Fd #define SQLITE_FCNTL_JOURNAL_POINTER
76.Fd #define SQLITE_FCNTL_WIN32_GET_HANDLE
77.Fd #define SQLITE_FCNTL_PDB
78.Fd #define SQLITE_FCNTL_BEGIN_ATOMIC_WRITE
79.Fd #define SQLITE_FCNTL_COMMIT_ATOMIC_WRITE
80.Fd #define SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE
81.Fd #define SQLITE_FCNTL_LOCK_TIMEOUT
82.Fd #define SQLITE_FCNTL_DATA_VERSION
83.Fd #define SQLITE_FCNTL_SIZE_LIMIT
84.Fd #define SQLITE_FCNTL_CKPT_DONE
85.Fd #define SQLITE_FCNTL_RESERVE_BYTES
86.Fd #define SQLITE_FCNTL_CKPT_START
87.Fd #define SQLITE_FCNTL_EXTERNAL_READER
88.Fd #define SQLITE_FCNTL_CKSM_FILE
89.Fd #define SQLITE_FCNTL_RESET_CACHE
90.Sh DESCRIPTION
91These integer constants are opcodes for the xFileControl method of
92the sqlite3_io_methods object and for the
93.Fn sqlite3_file_control
94interface.
95.Bl -bullet
96.It
97The SQLITE_FCNTL_LOCKSTATE opcode is used for
98debugging.
99This opcode causes the xFileControl method to write the current state
100of the lock (one of SQLITE_LOCK_NONE, SQLITE_LOCK_SHARED,
101SQLITE_LOCK_RESERVED, SQLITE_LOCK_PENDING,
102or SQLITE_LOCK_EXCLUSIVE) into an integer that
103the pArg argument points to.
104This capability is only available if SQLite is compiled with SQLITE_DEBUG.
105.It
106The SQLITE_FCNTL_SIZE_HINT opcode is used by
107SQLite to give the VFS layer a hint of how large the database file
108will grow to be during the current transaction.
109This hint is not guaranteed to be accurate but it is often close.
110The underlying VFS might choose to preallocate database file space
111based on this hint in order to help writes to the database file run
112faster.
113.It
114The SQLITE_FCNTL_SIZE_LIMIT opcode is used by
115in-memory VFS that implements
116.Fn sqlite3_deserialize
117to set an upper bound on the size of the in-memory database.
118The argument is a pointer to a sqlite3_int64.
119If the integer pointed to is negative, then it is filled in with the
120current limit.
121Otherwise the limit is set to the larger of the value of the integer
122pointed to and the current database size.
123The integer pointed to is set to the new limit.
124.It
125The SQLITE_FCNTL_CHUNK_SIZE opcode is used to
126request that the VFS extends and truncates the database file in chunks
127of a size specified by the user.
128The fourth argument to
129.Fn sqlite3_file_control
130should point to an integer (type int) containing the new chunk-size
131to use for the nominated database.
132Allocating database file space in large chunks (say 1MB at a time),
133may reduce file-system fragmentation and improve performance on some
134systems.
135.It
136The SQLITE_FCNTL_FILE_POINTER opcode is used
137to obtain a pointer to the sqlite3_file object associated
138with a particular database connection.
139See also SQLITE_FCNTL_JOURNAL_POINTER.
140.It
141The SQLITE_FCNTL_JOURNAL_POINTER opcode
142is used to obtain a pointer to the sqlite3_file object
143associated with the journal file (either the rollback journal
144or the write-ahead log) for a particular database connection.
145See also SQLITE_FCNTL_FILE_POINTER.
146.It
147No longer in use.
148.It
149The SQLITE_FCNTL_SYNC opcode is generated internally
150by SQLite and sent to the VFS immediately before the xSync method is
151invoked on a database file descriptor.
152Or, if the xSync method is not invoked because the user has configured
153SQLite with PRAGMA synchronous=OFF it is invoked
154in place of the xSync method.
155In most cases, the pointer argument passed with this file-control is
156NULL.
157However, if the database file is being synced as part of a multi-database
158commit, the argument points to a nul-terminated string containing the
159transactions super-journal file name.
160VFSes that do not need this signal should silently ignore this opcode.
161Applications should not call
162.Fn sqlite3_file_control
163with this opcode as doing so may disrupt the operation of the specialized
164VFSes that do require it.
165.It
166The SQLITE_FCNTL_COMMIT_PHASETWO opcode
167is generated internally by SQLite and sent to the VFS after a transaction
168has been committed immediately but before the database is unlocked.
169VFSes that do not need this signal should silently ignore this opcode.
170Applications should not call
171.Fn sqlite3_file_control
172with this opcode as doing so may disrupt the operation of the specialized
173VFSes that do require it.
174.It
175The SQLITE_FCNTL_WIN32_AV_RETRY opcode is
176used to configure automatic retry counts and intervals for certain
177disk I/O operations for the windows VFS in order to provide robustness
178in the presence of anti-virus programs.
179By default, the windows VFS will retry file read, file write, and file
180delete operations up to 10 times, with a delay of 25 milliseconds before
181the first retry and with the delay increasing by an additional 25 milliseconds
182with each subsequent retry.
183This opcode allows these two values (10 retries and 25 milliseconds
184of delay) to be adjusted.
185The values are changed for all database connections within the same
186process.
187The argument is a pointer to an array of two integers where the first
188integer is the new retry count and the second integer is the delay.
189If either integer is negative, then the setting is not changed but
190instead the prior value of that setting is written into the array entry,
191allowing the current retry settings to be interrogated.
192The zDbName parameter is ignored.
193.It
194The SQLITE_FCNTL_PERSIST_WAL opcode is used
195to set or query the persistent Write Ahead Log setting.
196By default, the auxiliary write ahead log (WAL file) and shared
197memory files used for transaction control are automatically deleted
198when the latest connection to the database closes.
199Setting persistent WAL mode causes those files to persist after close.
200Persisting the files is useful when other processes that do not have
201write permission on the directory containing the database file want
202to read the database file, as the WAL and shared memory files must
203exist in order for the database to be readable.
204The fourth parameter to
205.Fn sqlite3_file_control
206for this opcode should be a pointer to an integer.
207That integer is 0 to disable persistent WAL mode or 1 to enable persistent
208WAL mode.
209If the integer is -1, then it is overwritten with the current WAL persistence
210setting.
211.It
212The SQLITE_FCNTL_POWERSAFE_OVERWRITE
213opcode is used to set or query the persistent "powersafe-overwrite"
214or "PSOW" setting.
215The PSOW setting determines the SQLITE_IOCAP_POWERSAFE_OVERWRITE
216bit of the xDeviceCharacteristics methods.
217The fourth parameter to
218.Fn sqlite3_file_control
219for this opcode should be a pointer to an integer.
220That integer is 0 to disable zero-damage mode or 1 to enable zero-damage
221mode.
222If the integer is -1, then it is overwritten with the current zero-damage
223mode setting.
224.It
225The SQLITE_FCNTL_OVERWRITE opcode is invoked
226by SQLite after opening a write transaction to indicate that, unless
227it is rolled back for some reason, the entire database file will be
228overwritten by the current transaction.
229This is used by VACUUM operations.
230.It
231The SQLITE_FCNTL_VFSNAME opcode can be used to
232obtain the names of all VFSes in the VFS stack.
233The names are of all VFS shims and the final bottom-level VFS are written
234into memory obtained from
235.Fn sqlite3_malloc
236and the result is stored in the char* variable that the fourth parameter
237of
238.Fn sqlite3_file_control
239points to.
240The caller is responsible for freeing the memory when done.
241As with all file-control actions, there is no guarantee that this will
242actually do anything.
243Callers should initialize the char* variable to a NULL pointer in case
244this file-control is not implemented.
245This file-control is intended for diagnostic use only.
246.It
247The SQLITE_FCNTL_VFS_POINTER opcode finds a
248pointer to the top-level VFSes currently in use.
249The argument X in sqlite3_file_control(db,SQLITE_FCNTL_VFS_POINTER,X)
250must be of type "sqlite3_vfs **".
251This opcodes will set *X to a pointer to the top-level VFS.
252When there are multiple VFS shims in the stack, this opcode finds the
253upper-most shim only.
254.It
255Whenever a PRAGMA statement is parsed, an SQLITE_FCNTL_PRAGMA
256file control is sent to the open sqlite3_file object corresponding
257to the database file to which the pragma statement refers.
258The argument to the SQLITE_FCNTL_PRAGMA file control
259is an array of pointers to strings (char**) in which the second element
260of the array is the name of the pragma and the third element is the
261argument to the pragma or NULL if the pragma has no argument.
262The handler for an SQLITE_FCNTL_PRAGMA file control
263can optionally make the first element of the char** argument point
264to a string obtained from
265.Fn sqlite3_mprintf
266or the equivalent and that string will become the result of the pragma
267or the error message if the pragma fails.
268If the SQLITE_FCNTL_PRAGMA file control returns
269SQLITE_NOTFOUND, then normal PRAGMA processing
270continues.
271If the SQLITE_FCNTL_PRAGMA file control returns
272SQLITE_OK, then the parser assumes that the VFS has handled
273the PRAGMA itself and the parser generates a no-op prepared statement
274if result string is NULL, or that returns a copy of the result string
275if the string is non-NULL.
276If the SQLITE_FCNTL_PRAGMA file control returns
277any result code other than SQLITE_OK or SQLITE_NOTFOUND,
278that means that the VFS encountered an error while handling the PRAGMA
279and the compilation of the PRAGMA fails with an error.
280The SQLITE_FCNTL_PRAGMA file control occurs at the
281beginning of pragma statement analysis and so it is able to override
282built-in PRAGMA statements.
283.It
284The SQLITE_FCNTL_BUSYHANDLER file-control may
285be invoked by SQLite on the database file handle shortly after it is
286opened in order to provide a custom VFS with access to the connection's
287busy-handler callback.
288The argument is of type (void**) - an array of two (void *) values.
289The first (void *) actually points to a function of type (int (*)(void
290*)).
291In order to invoke the connection's busy-handler, this function should
292be invoked with the second (void *) in the array as the only argument.
293If it returns non-zero, then the operation should be retried.
294If it returns zero, the custom VFS should abandon the current operation.
295.It
296Applications can invoke the SQLITE_FCNTL_TEMPFILENAME
297file-control to have SQLite generate a temporary filename using the
298same algorithm that is followed to generate temporary filenames for
299TEMP tables and other internal uses.
300The argument should be a char** which will be filled with the filename
301written into memory obtained from
302.Fn sqlite3_malloc .
303The caller should invoke
304.Fn sqlite3_free
305on the result to avoid a memory leak.
306.It
307The SQLITE_FCNTL_MMAP_SIZE file control is used
308to query or set the maximum number of bytes that will be used for memory-mapped
309I/O.
310The argument is a pointer to a value of type sqlite3_int64 that is
311an advisory maximum number of bytes in the file to memory map.
312The pointer is overwritten with the old value.
313The limit is not changed if the value originally pointed to is negative,
314and so the current limit can be queried by passing in a pointer to
315a negative number.
316This file-control is used internally to implement PRAGMA mmap_size.
317.It
318The SQLITE_FCNTL_TRACE file control provides advisory
319information to the VFS about what the higher layers of the SQLite stack
320are doing.
321This file control is used by some VFS activity tracing shims.
322The argument is a zero-terminated string.
323Higher layers in the SQLite stack may generate instances of this file
324control if the SQLITE_USE_FCNTL_TRACE compile-time
325option is enabled.
326.It
327The SQLITE_FCNTL_HAS_MOVED file control interprets
328its argument as a pointer to an integer and it writes a boolean into
329that integer depending on whether or not the file has been renamed,
330moved, or deleted since it was first opened.
331.It
332The SQLITE_FCNTL_WIN32_GET_HANDLE opcode
333can be used to obtain the underlying native file handle associated
334with a file handle.
335This file control interprets its argument as a pointer to a native
336file handle and writes the resulting value there.
337.It
338The SQLITE_FCNTL_WIN32_SET_HANDLE opcode
339is used for debugging.
340This opcode causes the xFileControl method to swap the file handle
341with the one pointed to by the pArg argument.
342This capability is used during testing and only needs to be supported
343when SQLITE_TEST is defined.
344.It
345The SQLITE_FCNTL_WAL_BLOCK is a signal to the
346VFS layer that it might be advantageous to block on the next WAL lock
347if the lock is not immediately available.
348The WAL subsystem issues this signal during rare circumstances in order
349to fix a problem with priority inversion.
350Applications should \fBnot\fP use this file-control.
351.It
352The SQLITE_FCNTL_ZIPVFS opcode is implemented by
353zipvfs only.
354All other VFS should return SQLITE_NOTFOUND for this opcode.
355.It
356The SQLITE_FCNTL_RBU opcode is implemented by the special
357VFS used by the RBU extension only.
358All other VFS should return SQLITE_NOTFOUND for this opcode.
359.It
360If the SQLITE_FCNTL_BEGIN_ATOMIC_WRITE
361opcode returns SQLITE_OK, then the file descriptor is placed in "batch
362write mode", which means all subsequent write operations will be deferred
363and done atomically at the next SQLITE_FCNTL_COMMIT_ATOMIC_WRITE.
364Systems that do not support batch atomic writes will return SQLITE_NOTFOUND.
365Following a successful SQLITE_FCNTL_BEGIN_ATOMIC_WRITE and prior to
366the closing SQLITE_FCNTL_COMMIT_ATOMIC_WRITE
367or SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE,
368SQLite will make no VFS interface calls on the same sqlite3_file
369file descriptor except for calls to the xWrite method and the xFileControl
370method with SQLITE_FCNTL_SIZE_HINT.
371.It
372The SQLITE_FCNTL_COMMIT_ATOMIC_WRITE
373opcode causes all write operations since the previous successful call
374to SQLITE_FCNTL_BEGIN_ATOMIC_WRITE to
375be performed atomically.
376This file control returns SQLITE_OK if and only if the writes
377were all performed successfully and have been committed to persistent
378storage.
379Regardless of whether or not it is successful, this file control takes
380the file descriptor out of batch write mode so that all subsequent
381write operations are independent.
382SQLite will never invoke SQLITE_FCNTL_COMMIT_ATOMIC_WRITE without a
383prior successful call to SQLITE_FCNTL_BEGIN_ATOMIC_WRITE.
384.It
385The SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE
386opcode causes all write operations since the previous successful call
387to SQLITE_FCNTL_BEGIN_ATOMIC_WRITE to
388be rolled back.
389This file control takes the file descriptor out of batch write mode
390so that all subsequent write operations are independent.
391SQLite will never invoke SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE without
392a prior successful call to SQLITE_FCNTL_BEGIN_ATOMIC_WRITE.
393.It
394The SQLITE_FCNTL_LOCK_TIMEOUT opcode is used
395to configure a VFS to block for up to M milliseconds before failing
396when attempting to obtain a file lock using the xLock or xShmLock methods
397of the VFS.
398The parameter is a pointer to a 32-bit signed integer that contains
399the value that M is to be set to.
400Before returning, the 32-bit signed integer is overwritten with the
401previous value of M.
402.It
403The SQLITE_FCNTL_DATA_VERSION opcode is used
404to detect changes to a database file.
405The argument is a pointer to a 32-bit unsigned integer.
406The "data version" for the pager is written into the pointer.
407The "data version" changes whenever any change occurs to the corresponding
408database file, either through SQL statements on the same database connection
409or through transactions committed by separate database connections
410possibly in other processes.
411The
412.Fn sqlite3_total_changes
413interface can be used to find if any database on the connection has
414changed, but that interface responds to changes on TEMP as well as
415MAIN and does not provide a mechanism to detect changes to MAIN only.
416Also, the
417.Fn sqlite3_total_changes
418interface responds to internal changes only and omits changes made
419by other database connections.
420The PRAGMA data_version command provides a mechanism
421to detect changes to a single attached database that occur due to other
422database connections, but omits changes implemented by the database
423connection on which it is called.
424This file control is the only mechanism to detect changes that happen
425either internally or externally and that are associated with a particular
426attached database.
427.It
428The SQLITE_FCNTL_CKPT_START opcode is invoked
429from within a checkpoint in wal mode before the client starts to copy
430pages from the wal file to the database file.
431.It
432The SQLITE_FCNTL_CKPT_DONE opcode is invoked
433from within a checkpoint in wal mode after the client has finished
434copying pages from the wal file to the database file, but before the
435*-shm file is updated to record the fact that the pages have been checkpointed.
436.It
437The EXPERIMENTAL SQLITE_FCNTL_EXTERNAL_READER
438opcode is used to detect whether or not there is a database client
439in another process with a wal-mode transaction open on the database
440or not.
441It is only available on unix.The (void*) argument passed with this
442file-control should be a pointer to a value of type (int).
443The integer value is set to 1 if the database is a wal mode database
444and there exists at least one client in another process that currently
445has an SQL transaction open on the database.
446It is set to 0 if the database is not a wal-mode db, or if there is
447no such connection in any other process.
448This opcode cannot be used to detect transactions opened by clients
449within the current process, only within other processes.
450.It
451The SQLITE_FCNTL_CKSM_FILE opcode is for use
452internally by the checksum VFS shim only.
453.It
454If there is currently no transaction open on the database, and the
455database is not a temp db, then the SQLITE_FCNTL_RESET_CACHE
456file-control purges the contents of the in-memory page cache.
457If there is an open transaction, or if the db is a temp-db, this opcode
458is a no-op, not an error.
459.El
460.Pp
461.Sh IMPLEMENTATION NOTES
462These declarations were extracted from the
463interface documentation at line 862.
464.Bd -literal
465#define SQLITE_FCNTL_LOCKSTATE               1
466#define SQLITE_FCNTL_GET_LOCKPROXYFILE       2
467#define SQLITE_FCNTL_SET_LOCKPROXYFILE       3
468#define SQLITE_FCNTL_LAST_ERRNO              4
469#define SQLITE_FCNTL_SIZE_HINT               5
470#define SQLITE_FCNTL_CHUNK_SIZE              6
471#define SQLITE_FCNTL_FILE_POINTER            7
472#define SQLITE_FCNTL_SYNC_OMITTED            8
473#define SQLITE_FCNTL_WIN32_AV_RETRY          9
474#define SQLITE_FCNTL_PERSIST_WAL            10
475#define SQLITE_FCNTL_OVERWRITE              11
476#define SQLITE_FCNTL_VFSNAME                12
477#define SQLITE_FCNTL_POWERSAFE_OVERWRITE    13
478#define SQLITE_FCNTL_PRAGMA                 14
479#define SQLITE_FCNTL_BUSYHANDLER            15
480#define SQLITE_FCNTL_TEMPFILENAME           16
481#define SQLITE_FCNTL_MMAP_SIZE              18
482#define SQLITE_FCNTL_TRACE                  19
483#define SQLITE_FCNTL_HAS_MOVED              20
484#define SQLITE_FCNTL_SYNC                   21
485#define SQLITE_FCNTL_COMMIT_PHASETWO        22
486#define SQLITE_FCNTL_WIN32_SET_HANDLE       23
487#define SQLITE_FCNTL_WAL_BLOCK              24
488#define SQLITE_FCNTL_ZIPVFS                 25
489#define SQLITE_FCNTL_RBU                    26
490#define SQLITE_FCNTL_VFS_POINTER            27
491#define SQLITE_FCNTL_JOURNAL_POINTER        28
492#define SQLITE_FCNTL_WIN32_GET_HANDLE       29
493#define SQLITE_FCNTL_PDB                    30
494#define SQLITE_FCNTL_BEGIN_ATOMIC_WRITE     31
495#define SQLITE_FCNTL_COMMIT_ATOMIC_WRITE    32
496#define SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE  33
497#define SQLITE_FCNTL_LOCK_TIMEOUT           34
498#define SQLITE_FCNTL_DATA_VERSION           35
499#define SQLITE_FCNTL_SIZE_LIMIT             36
500#define SQLITE_FCNTL_CKPT_DONE              37
501#define SQLITE_FCNTL_RESERVE_BYTES          38
502#define SQLITE_FCNTL_CKPT_START             39
503#define SQLITE_FCNTL_EXTERNAL_READER        40
504#define SQLITE_FCNTL_CKSM_FILE              41
505#define SQLITE_FCNTL_RESET_CACHE            42
506.Ed
507.Sh SEE ALSO
508.Xr sqlite3_deserialize 3 ,
509.Xr sqlite3_file 3 ,
510.Xr sqlite3_file_control 3 ,
511.Xr sqlite3_io_methods 3 ,
512.Xr sqlite3_malloc 3 ,
513.Xr sqlite3_mprintf 3 ,
514.Xr sqlite3_total_changes 3 ,
515.Xr sqlite3_vfs 3 ,
516.Xr sqlite_int64 3 ,
517.Xr SQLITE_IOCAP_ATOMIC 3 ,
518.Xr SQLITE_LOCK_NONE 3 ,
519.Xr SQLITE_OK 3
520