| blob | 1acbcca4695b04a687b7dbf427cc1ae95a799678 |
1 /*
2 ** 2014 August 30
3 **
4 ** The author disclaims copyright to this source code. In place of
5 ** a legal notice, here is a blessing:
6 **
7 ** May you do good and not evil.
8 ** May you find forgiveness for yourself and forgive others.
9 ** May you share freely, never taking more than you give.
10 **
11 *************************************************************************
12 **
13 ** This file contains the public interface for the RBU extension.
14 */
16 /*
17 ** SUMMARY
18 **
19 ** Writing a transaction containing a large number of operations on
20 ** b-tree indexes that are collectively larger than the available cache
21 ** memory can be very inefficient.
22 **
23 ** The problem is that in order to update a b-tree, the leaf page (at least)
24 ** containing the entry being inserted or deleted must be modified. If the
25 ** working set of leaves is larger than the available cache memory, then a
26 ** single leaf that is modified more than once as part of the transaction
27 ** may be loaded from or written to the persistent media multiple times.
28 ** Additionally, because the index updates are likely to be applied in
29 ** random order, access to pages within the database is also likely to be in
30 ** random order, which is itself quite inefficient.
31 **
32 ** One way to improve the situation is to sort the operations on each index
33 ** by index key before applying them to the b-tree. This leads to an IO
34 ** pattern that resembles a single linear scan through the index b-tree,
35 ** and all but guarantees each modified leaf page is loaded and stored
36 ** exactly once. SQLite uses this trick to improve the performance of
37 ** CREATE INDEX commands. This extension allows it to be used to improve
38 ** the performance of large transactions on existing databases.
39 **
40 ** Additionally, this extension allows the work involved in writing the
41 ** large transaction to be broken down into sub-transactions performed
42 ** sequentially by separate processes. This is useful if the system cannot
43 ** guarantee that a single update process will run for long enough to apply
44 ** the entire update, for example because the update is being applied on a
45 ** mobile device that is frequently rebooted. Even after the writer process
46 ** has committed one or more sub-transactions, other database clients continue
47 ** to read from the original database snapshot. In other words, partially
48 ** applied transactions are not visible to other clients.
49 **
50 ** "RBU" stands for "Resumable Bulk Update". As in a large database update
51 ** transmitted via a wireless network to a mobile device. A transaction
52 ** applied using this extension is hence refered to as an "RBU update".
53 **
54 **
55 ** LIMITATIONS
56 **
57 ** An "RBU update" transaction is subject to the following limitations:
58 **
59 ** * The transaction must consist of INSERT, UPDATE and DELETE operations
60 ** only.
61 **
62 ** * INSERT statements may not use any default values.
63 **
64 ** * UPDATE and DELETE statements must identify their target rows by
65 ** non-NULL PRIMARY KEY values. Rows with NULL values stored in PRIMARY
66 ** KEY fields may not be updated or deleted. If the table being written
67 ** has no PRIMARY KEY, affected rows must be identified by rowid.
68 **
69 ** * UPDATE statements may not modify PRIMARY KEY columns.
70 **
71 ** * No triggers will be fired.
72 **
73 ** * No foreign key violations are detected or reported.
74 **
75 ** * CHECK constraints are not enforced.
76 **
77 ** * No constraint handling mode except for "OR ROLLBACK" is supported.
78 **
79 **
80 ** PREPARATION
81 **
82 ** An "RBU update" is stored as a separate SQLite database. A database
83 ** containing an RBU update is an "RBU database". For each table in the
84 ** target database to be updated, the RBU database should contain a table
85 ** named "data_<target name>" containing the same set of columns as the
86 ** target table, and one more - "rbu_control". The data_% table should
87 ** have no PRIMARY KEY or UNIQUE constraints, but each column should have
88 ** the same type as the corresponding column in the target database.
89 ** The "rbu_control" column should have no type at all. For example, if
90 ** the target database contains:
91 **
92 ** CREATE TABLE t1(a INTEGER PRIMARY KEY, b TEXT, c UNIQUE);
93 **
94 ** Then the RBU database should contain:
95 **
96 ** CREATE TABLE data_t1(a INTEGER, b TEXT, c, rbu_control);
97 **
98 ** The order of the columns in the data_% table does not matter.
99 **
100 ** Instead of a regular table, the RBU database may also contain virtual
101 ** tables or view named using the data_<target> naming scheme.
102 **
103 ** Instead of the plain data_<target> naming scheme, RBU database tables
104 ** may also be named data<integer>_<target>, where <integer> is any sequence
105 ** of zero or more numeric characters (0-9). This can be significant because
106 ** tables within the RBU database are always processed in order sorted by
107 ** name. By judicious selection of the <integer> portion of the names
108 ** of the RBU tables the user can therefore control the order in which they
109 ** are processed. This can be useful, for example, to ensure that "external
110 ** content" FTS4 tables are updated before their underlying content tables.
111 **
112 ** If the target database table is a virtual table or a table that has no
113 ** PRIMARY KEY declaration, the data_% table must also contain a column
114 ** named "rbu_rowid". This column is mapped to the tables implicit primary
115 ** key column - "rowid". Virtual tables for which the "rowid" column does
116 ** not function like a primary key value cannot be updated using RBU. For
117 ** example, if the target db contains either of the following:
118 **
119 ** CREATE VIRTUAL TABLE x1 USING fts3(a, b);
120 ** CREATE TABLE x1(a, b)
121 **
122 ** then the RBU database should contain:
123 **
124 ** CREATE TABLE data_x1(a, b, rbu_rowid, rbu_control);
125 **
126 ** All non-hidden columns (i.e. all columns matched by "SELECT *") of the
127 ** target table must be present in the input table. For virtual tables,
128 ** hidden columns are optional - they are updated by RBU if present in
129 ** the input table, or not otherwise. For example, to write to an fts4
130 ** table with a hidden languageid column such as:
131 **
132 ** CREATE VIRTUAL TABLE ft1 USING fts4(a, b, languageid='langid');
133 **
134 ** Either of the following input table schemas may be used:
135 **
136 ** CREATE TABLE data_ft1(a, b, langid, rbu_rowid, rbu_control);
137 ** CREATE TABLE data_ft1(a, b, rbu_rowid, rbu_control);
138 **
139 ** For each row to INSERT into the target database as part of the RBU
140 ** update, the corresponding data_% table should contain a single record
141 ** with the "rbu_control" column set to contain integer value 0. The
142 ** other columns should be set to the values that make up the new record
143 ** to insert.
144 **
145 ** If the target database table has an INTEGER PRIMARY KEY, it is not
146 ** possible to insert a NULL value into the IPK column. Attempting to
147 ** do so results in an SQLITE_MISMATCH error.
148 **
149 ** For each row to DELETE from the target database as part of the RBU
150 ** update, the corresponding data_% table should contain a single record
151 ** with the "rbu_control" column set to contain integer value 1. The
152 ** real primary key values of the row to delete should be stored in the
153 ** corresponding columns of the data_% table. The values stored in the
154 ** other columns are not used.
155 **
156 ** For each row to UPDATE from the target database as part of the RBU
157 ** update, the corresponding data_% table should contain a single record
158 ** with the "rbu_control" column set to contain a value of type text.
159 ** The real primary key values identifying the row to update should be
160 ** stored in the corresponding columns of the data_% table row, as should
161 ** the new values of all columns being update. The text value in the
162 ** "rbu_control" column must contain the same number of characters as
163 ** there are columns in the target database table, and must consist entirely
164 ** of 'x' and '.' characters (or in some special cases 'd' - see below). For
165 ** each column that is being updated, the corresponding character is set to
166 ** 'x'. For those that remain as they are, the corresponding character of the
167 ** rbu_control value should be set to '.'. For example, given the tables
168 ** above, the update statement:
169 **
170 ** UPDATE t1 SET c = 'usa' WHERE a = 4;
171 **
172 ** is represented by the data_t1 row created by:
173 **
174 ** INSERT INTO data_t1(a, b, c, rbu_control) VALUES(4, NULL, 'usa', '..x');
175 **
176 ** Instead of an 'x' character, characters of the rbu_control value specified
177 ** for UPDATEs may also be set to 'd'. In this case, instead of updating the
178 ** target table with the value stored in the corresponding data_% column, the
179 ** user-defined SQL function "rbu_delta()" is invoked and the result stored in
180 ** the target table column. rbu_delta() is invoked with two arguments - the
181 ** original value currently stored in the target table column and the
182 ** value specified in the data_xxx table.
183 **
184 ** For example, this row:
185 **
186 ** INSERT INTO data_t1(a, b, c, rbu_control) VALUES(4, NULL, 'usa', '..d');
187 **
188 ** is similar to an UPDATE statement such as:
189 **
190 ** UPDATE t1 SET c = rbu_delta(c, 'usa') WHERE a = 4;
191 **
192 ** Finally, if an 'f' character appears in place of a 'd' or 's' in an
193 ** ota_control string, the contents of the data_xxx table column is assumed
194 ** to be a "fossil delta" - a patch to be applied to a blob value in the
195 ** format used by the fossil source-code management system. In this case
196 ** the existing value within the target database table must be of type BLOB.
197 ** It is replaced by the result of applying the specified fossil delta to
198 ** itself.
199 **
200 ** If the target database table is a virtual table or a table with no PRIMARY
201 ** KEY, the rbu_control value should not include a character corresponding
202 ** to the rbu_rowid value. For example, this:
203 **
204 ** INSERT INTO data_ft1(a, b, rbu_rowid, rbu_control)
205 ** VALUES(NULL, 'usa', 12, '.x');
206 **
207 ** causes a result similar to:
208 **
209 ** UPDATE ft1 SET b = 'usa' WHERE rowid = 12;
210 **
211 ** The data_xxx tables themselves should have no PRIMARY KEY declarations.
212 ** However, RBU is more efficient if reading the rows in from each data_xxx
213 ** table in "rowid" order is roughly the same as reading them sorted by
214 ** the PRIMARY KEY of the corresponding target database table. In other
215 ** words, rows should be sorted using the destination table PRIMARY KEY
216 ** fields before they are inserted into the data_xxx tables.
217 **
218 ** USAGE
219 **
220 ** The API declared below allows an application to apply an RBU update
221 ** stored on disk to an existing target database. Essentially, the
222 ** application:
223 **
224 ** 1) Opens an RBU handle using the sqlite3rbu_open() function.
225 **
226 ** 2) Registers any required virtual table modules with the database
227 ** handle returned by sqlite3rbu_db(). Also, if required, register
228 ** the rbu_delta() implementation.
229 **
230 ** 3) Calls the sqlite3rbu_step() function one or more times on
231 ** the new handle. Each call to sqlite3rbu_step() performs a single
232 ** b-tree operation, so thousands of calls may be required to apply
233 ** a complete update.
234 **
235 ** 4) Calls sqlite3rbu_close() to close the RBU update handle. If
236 ** sqlite3rbu_step() has been called enough times to completely
237 ** apply the update to the target database, then the RBU database
238 ** is marked as fully applied. Otherwise, the state of the RBU
239 ** update application is saved in the RBU database for later
240 ** resumption.
241 **
242 ** See comments below for more detail on APIs.
243 **
244 ** If an update is only partially applied to the target database by the
245 ** time sqlite3rbu_close() is called, various state information is saved
246 ** within the RBU database. This allows subsequent processes to automatically
247 ** resume the RBU update from where it left off.
248 **
249 ** To remove all RBU extension state information, returning an RBU database
250 ** to its original contents, it is sufficient to drop all tables that begin
251 ** with the prefix "rbu_"
252 **
253 ** DATABASE LOCKING
254 **
255 ** An RBU update may not be applied to a database in WAL mode. Attempting
256 ** to do so is an error (SQLITE_ERROR).
257 **
258 ** While an RBU handle is open, a SHARED lock may be held on the target
259 ** database file. This means it is possible for other clients to read the
260 ** database, but not to write it.
261 **
262 ** If an RBU update is started and then suspended before it is completed,
263 ** then an external client writes to the database, then attempting to resume
264 ** the suspended RBU update is also an error (SQLITE_BUSY).
265 */
267 #ifndef _SQLITE3RBU_H
268 #define _SQLITE3RBU_H
272 #ifdef __cplusplus
274 #endif
278 /*
279 ** Open an RBU handle.
280 **
281 ** Argument zTarget is the path to the target database. Argument zRbu is
282 ** the path to the RBU database. Each call to this function must be matched
283 ** by a call to sqlite3rbu_close(). When opening the databases, RBU passes
284 ** the SQLITE_CONFIG_URI flag to sqlite3_open_v2(). So if either zTarget
285 ** or zRbu begin with "file:", it will be interpreted as an SQLite
286 ** database URI, not a regular file name.
287 **
288 ** If the zState argument is passed a NULL value, the RBU extension stores
289 ** the current state of the update (how many rows have been updated, which
290 ** indexes are yet to be updated etc.) within the RBU database itself. This
291 ** can be convenient, as it means that the RBU application does not need to
292 ** organize removing a separate state file after the update is concluded.
293 ** Or, if zState is non-NULL, it must be a path to a database file in which
294 ** the RBU extension can store the state of the update.
295 **
296 ** When resuming an RBU update, the zState argument must be passed the same
297 ** value as when the RBU update was started.
298 **
299 ** Once the RBU update is finished, the RBU extension does not
300 ** automatically remove any zState database file, even if it created it.
301 **
302 ** By default, RBU uses the default VFS to access the files on disk. To
303 ** use a VFS other than the default, an SQLite "file:" URI containing a
304 ** "vfs=..." option may be passed as the zTarget option.
305 **
306 ** IMPORTANT NOTE FOR ZIPVFS USERS: The RBU extension works with all of
307 ** SQLite's built-in VFSs, including the multiplexor VFS. However it does
308 ** not work out of the box with zipvfs. Refer to the comment describing
309 ** the zipvfs_create_vfs() API below for details on using RBU with zipvfs.
310 */
315 );
317 /*
318 ** Open an RBU handle to perform an RBU vacuum on database file zTarget.
319 ** An RBU vacuum is similar to SQLite's built-in VACUUM command, except
320 ** that it can be suspended and resumed like an RBU update.
321 **
322 ** The second argument to this function identifies a database in which
323 ** to store the state of the RBU vacuum operation if it is suspended. The
324 ** first time sqlite3rbu_vacuum() is called, to start an RBU vacuum
325 ** operation, the state database should either not exist or be empty
326 ** (contain no tables). If an RBU vacuum is suspended by calling
327 ** sqlite3rbu_close() on the RBU handle before sqlite3rbu_step() has
328 ** returned SQLITE_DONE, the vacuum state is stored in the state database.
329 ** The vacuum can be resumed by calling this function to open a new RBU
330 ** handle specifying the same target and state databases.
331 **
332 ** If the second argument passed to this function is NULL, then the
333 ** name of the state database is "<database>-vacuum", where <database>
334 ** is the name of the target database file. In this case, on UNIX, if the
335 ** state database is not already present in the file-system, it is created
336 ** with the same permissions as the target db is made.
337 **
338 ** This function does not delete the state database after an RBU vacuum
339 ** is completed, even if it created it. However, if the call to
340 ** sqlite3rbu_close() returns any value other than SQLITE_OK, the contents
341 ** of the state tables within the state database are zeroed. This way,
342 ** the next call to sqlite3rbu_vacuum() opens a handle that starts a
343 ** new RBU vacuum operation.
344 **
345 ** As with sqlite3rbu_open(), Zipvfs users should rever to the comment
346 ** describing the sqlite3rbu_create_vfs() API function below for
347 ** a description of the complications associated with using RBU with
348 ** zipvfs databases.
349 */
353 );
355 /*
356 ** Configure a limit for the amount of temp space that may be used by
357 ** the RBU handle passed as the first argument. The new limit is specified
358 ** in bytes by the second parameter. If it is positive, the limit is updated.
359 ** If the second parameter to this function is passed zero, then the limit
360 ** is removed entirely. If the second parameter is negative, the limit is
361 ** not modified (this is useful for querying the current limit).
362 **
363 ** In all cases the returned value is the current limit in bytes (zero
364 ** indicates unlimited).
365 **
366 ** If the temp space limit is exceeded during operation, an SQLITE_FULL
367 ** error is returned.
368 */
371 /*
372 ** Return the current amount of temp file space, in bytes, currently used by
373 ** the RBU handle passed as the only argument.
374 */
377 /*
378 ** Internally, each RBU connection uses a separate SQLite database
379 ** connection to access the target and rbu update databases. This
380 ** API allows the application direct access to these database handles.
381 **
382 ** The first argument passed to this function must be a valid, open, RBU
383 ** handle. The second argument should be passed zero to access the target
384 ** database handle, or non-zero to access the rbu update database handle.
385 ** Accessing the underlying database handles may be useful in the
386 ** following scenarios:
387 **
388 ** * If any target tables are virtual tables, it may be necessary to
389 ** call sqlite3_create_module() on the target database handle to
390 ** register the required virtual table implementations.
391 **
392 ** * If the data_xxx tables in the RBU source database are virtual
393 ** tables, the application may need to call sqlite3_create_module() on
394 ** the rbu update db handle to any required virtual table
395 ** implementations.
396 **
397 ** * If the application uses the "rbu_delta()" feature described above,
398 ** it must use sqlite3_create_function() or similar to register the
399 ** rbu_delta() implementation with the target database handle.
400 **
401 ** If an error has occurred, either while opening or stepping the RBU object,
402 ** this function may return NULL. The error code and message may be collected
403 ** when sqlite3rbu_close() is called.
404 **
405 ** Database handles returned by this function remain valid until the next
406 ** call to any sqlite3rbu_xxx() function other than sqlite3rbu_db().
407 */
410 /*
411 ** Do some work towards applying the RBU update to the target db.
412 **
413 ** Return SQLITE_DONE if the update has been completely applied, or
414 ** SQLITE_OK if no error occurs but there remains work to do to apply
415 ** the RBU update. If an error does occur, some other error code is
416 ** returned.
417 **
418 ** Once a call to sqlite3rbu_step() has returned a value other than
419 ** SQLITE_OK, all subsequent calls on the same RBU handle are no-ops
420 ** that immediately return the same value.
421 */
424 /*
425 ** Force RBU to save its state to disk.
426 **
427 ** If a power failure or application crash occurs during an update, following
428 ** system recovery RBU may resume the update from the point at which the state
429 ** was last saved. In other words, from the most recent successful call to
430 ** sqlite3rbu_close() or this function.
431 **
432 ** SQLITE_OK is returned if successful, or an SQLite error code otherwise.
433 */
436 /*
437 ** Close an RBU handle.
438 **
439 ** If the RBU update has been completely applied, mark the RBU database
440 ** as fully applied. Otherwise, assuming no error has occurred, save the
441 ** current state of the RBU update appliation to the RBU database.
442 **
443 ** If an error has already occurred as part of an sqlite3rbu_step()
444 ** or sqlite3rbu_open() call, or if one occurs within this function, an
445 ** SQLite error code is returned. Additionally, if pzErrmsg is not NULL,
446 ** *pzErrmsg may be set to point to a buffer containing a utf-8 formatted
447 ** English language error message. It is the responsibility of the caller to
448 ** eventually free any such buffer using sqlite3_free().
449 **
450 ** Otherwise, if no error occurs, this function returns SQLITE_OK if the
451 ** update has been partially applied, or SQLITE_DONE if it has been
452 ** completely applied.
453 */
456 /*
457 ** Return the total number of key-value operations (inserts, deletes or
458 ** updates) that have been performed on the target database since the
459 ** current RBU update was started.
460 */
463 /*
464 ** Obtain permyriadage (permyriadage is to 10000 as percentage is to 100)
465 ** progress indications for the two stages of an RBU update. This API may
466 ** be useful for driving GUI progress indicators and similar.
467 **
468 ** An RBU update is divided into two stages:
469 **
470 ** * Stage 1, in which changes are accumulated in an oal/wal file, and
471 ** * Stage 2, in which the contents of the wal file are copied into the
472 ** main database.
473 **
474 ** The update is visible to non-RBU clients during stage 2. During stage 1
475 ** non-RBU reader clients may see the original database.
476 **
477 ** If this API is called during stage 2 of the update, output variable
478 ** (*pnOne) is set to 10000 to indicate that stage 1 has finished and (*pnTwo)
479 ** to a value between 0 and 10000 to indicate the permyriadage progress of
480 ** stage 2. A value of 5000 indicates that stage 2 is half finished,
481 ** 9000 indicates that it is 90% finished, and so on.
482 **
483 ** If this API is called during stage 1 of the update, output variable
484 ** (*pnTwo) is set to 0 to indicate that stage 2 has not yet started. The
485 ** value to which (*pnOne) is set depends on whether or not the RBU
486 ** database contains an "rbu_count" table. The rbu_count table, if it
487 ** exists, must contain the same columns as the following:
488 **
489 ** CREATE TABLE rbu_count(tbl TEXT PRIMARY KEY, cnt INTEGER) WITHOUT ROWID;
490 **
491 ** There must be one row in the table for each source (data_xxx) table within
492 ** the RBU database. The 'tbl' column should contain the name of the source
493 ** table. The 'cnt' column should contain the number of rows within the
494 ** source table.
495 **
496 ** If the rbu_count table is present and populated correctly and this
497 ** API is called during stage 1, the *pnOne output variable is set to the
498 ** permyriadage progress of the same stage. If the rbu_count table does
499 ** not exist, then (*pnOne) is set to -1 during stage 1. If the rbu_count
500 ** table exists but is not correctly populated, the value of the *pnOne
501 ** output variable during stage 1 is undefined.
502 */
505 /*
506 ** Obtain an indication as to the current stage of an RBU update or vacuum.
507 ** This function always returns one of the SQLITE_RBU_STATE_XXX constants
508 ** defined in this file. Return values should be interpreted as follows:
509 **
510 ** SQLITE_RBU_STATE_OAL:
511 ** RBU is currently building a *-oal file. The next call to sqlite3rbu_step()
512 ** may either add further data to the *-oal file, or compute data that will
513 ** be added by a subsequent call.
514 **
515 ** SQLITE_RBU_STATE_MOVE:
516 ** RBU has finished building the *-oal file. The next call to sqlite3rbu_step()
517 ** will move the *-oal file to the equivalent *-wal path. If the current
518 ** operation is an RBU update, then the updated version of the database
519 ** file will become visible to ordinary SQLite clients following the next
520 ** call to sqlite3rbu_step().
521 **
522 ** SQLITE_RBU_STATE_CHECKPOINT:
523 ** RBU is currently performing an incremental checkpoint. The next call to
524 ** sqlite3rbu_step() will copy a page of data from the *-wal file into
525 ** the target database file.
526 **
527 ** SQLITE_RBU_STATE_DONE:
528 ** The RBU operation has finished. Any subsequent calls to sqlite3rbu_step()
529 ** will immediately return SQLITE_DONE.
530 **
531 ** SQLITE_RBU_STATE_ERROR:
532 ** An error has occurred. Any subsequent calls to sqlite3rbu_step() will
533 ** immediately return the SQLite error code associated with the error.
534 */
535 #define SQLITE_RBU_STATE_OAL 1
536 #define SQLITE_RBU_STATE_MOVE 2
537 #define SQLITE_RBU_STATE_CHECKPOINT 3
538 #define SQLITE_RBU_STATE_DONE 4
539 #define SQLITE_RBU_STATE_ERROR 5
543 /*
544 ** Create an RBU VFS named zName that accesses the underlying file-system
545 ** via existing VFS zParent. Or, if the zParent parameter is passed NULL,
546 ** then the new RBU VFS uses the default system VFS to access the file-system.
547 ** The new object is registered as a non-default VFS with SQLite before
548 ** returning.
549 **
550 ** Part of the RBU implementation uses a custom VFS object. Usually, this
551 ** object is created and deleted automatically by RBU.
552 **
553 ** The exception is for applications that also use zipvfs. In this case,
554 ** the custom VFS must be explicitly created by the user before the RBU
555 ** handle is opened. The RBU VFS should be installed so that the zipvfs
556 ** VFS uses the RBU VFS, which in turn uses any other VFS layers in use
557 ** (for example multiplexor) to access the file-system. For example,
558 ** to assemble an RBU enabled VFS stack that uses both zipvfs and
559 ** multiplexor (error checking omitted):
560 **
561 ** // Create a VFS named "multiplex" (not the default).
562 ** sqlite3_multiplex_initialize(0, 0);
563 **
564 ** // Create an rbu VFS named "rbu" that uses multiplexor. If the
565 ** // second argument were replaced with NULL, the "rbu" VFS would
566 ** // access the file-system via the system default VFS, bypassing the
567 ** // multiplexor.
568 ** sqlite3rbu_create_vfs("rbu", "multiplex");
569 **
570 ** // Create a zipvfs VFS named "zipvfs" that uses rbu.
571 ** zipvfs_create_vfs_v3("zipvfs", "rbu", 0, xCompressorAlgorithmDetector);
572 **
573 ** // Make zipvfs the default VFS.
574 ** sqlite3_vfs_register(sqlite3_vfs_find("zipvfs"), 1);
575 **
576 ** Because the default VFS created above includes a RBU functionality, it
577 ** may be used by RBU clients. Attempting to use RBU with a zipvfs VFS stack
578 ** that does not include the RBU layer results in an error.
579 **
580 ** The overhead of adding the "rbu" VFS to the system is negligible for
581 ** non-RBU users. There is no harm in an application accessing the
582 ** file-system via "rbu" all the time, even if it only uses RBU functionality
583 ** occasionally.
584 */
587 /*
588 ** Deregister and destroy an RBU vfs created by an earlier call to
589 ** sqlite3rbu_create_vfs().
590 **
591 ** VFS objects are not reference counted. If a VFS object is destroyed
592 ** before all database handles that use it have been closed, the results
593 ** are undefined.
594 */
597 #ifdef __cplusplus
599 #endif