From 65578341af1ae50e52e0f45e691ce88ad5a1b9b1 Mon Sep 17 00:00:00 2001 From: Teodor Sigaev Date: Fri, 1 Apr 2016 12:21:48 +0300 Subject: Add Generic WAL interface This interface is designed to give an access to WAL for extensions which could implement new access method, for example. Previously it was impossible because restoring from custom WAL would need to access system catalog to find a redo custom function. This patch suggests generic way to describe changes on page with standart layout. Bump XLOG_PAGE_MAGIC because of new record type. Author: Alexander Korotkov with a help of Petr Jelinek, Markus Nullmeier and minor editorization by my Reviewers: Petr Jelinek, Alvaro Herrera, Teodor Sigaev, Jim Nasby, Michael Paquier --- doc/src/sgml/filelist.sgml | 1 + doc/src/sgml/generic-wal.sgml | 141 ++++++++++++++++++++++++++++++++++++++++++ doc/src/sgml/postgres.sgml | 1 + 3 files changed, 143 insertions(+) create mode 100644 doc/src/sgml/generic-wal.sgml (limited to 'doc/src') diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml index 30adecee367..9046f506281 100644 --- a/doc/src/sgml/filelist.sgml +++ b/doc/src/sgml/filelist.sgml @@ -100,6 +100,7 @@ + diff --git a/doc/src/sgml/generic-wal.sgml b/doc/src/sgml/generic-wal.sgml new file mode 100644 index 00000000000..6655f22f3a7 --- /dev/null +++ b/doc/src/sgml/generic-wal.sgml @@ -0,0 +1,141 @@ + + + + Generic WAL records + + + Despite all built-in access methods and WAL-logged modules having their own + types of WAL records, there is also a generic WAL record type, which describes + changes to pages in a generic way. This is useful for extensions that + provide custom access methods, because they cannot register their own + WAL redo routines. + + + + The API for contructing generic WAL records is defined in + generic_xlog.h and implemented in generic_xlog.c. + Each generic WAL record must be constructed by following these steps: + + + + + state = GenericXLogStart(relation) — start + construction of a generic xlog record for the given relation. + + + + + + page = GenericXLogRegister(state, buffer, isNew) — + register one or more buffers (one at a time) for the current generic + xlog record. This function returns a copy of the page image, where + modifications can be made. The second argument indicates if the page + is new (eventually, this will result in a full page image being put into + the xlog record). + + + + + + Apply modifications to page images obtained in the previous step. + + + + + + GenericXLogAbort(state) — finish construction of + a generic xlog record. + + + + + + + The xlog record construction can be canceled between any of the above + steps by calling GenericXLogAbort(). This will discard all + changes to the page image copies. + + + + Please note the following points when constructing generic xlog records: + + + + No direct modifications of page images are allowed! All modifications + must be done in copies acquired from GenericXLogRegister(). + In other words, code which makes generic xlog records must never call + BufferGetPage(). + + + + + + Registrations of buffers (step 2) and modifications of page images + (step 3) can be mixed freely, i.e., both steps may be repeated in any + sequence. The only restriction is that you can modify a page image + only after the registration of the corresponding buffer. + + + + + + After registration, the buffer can also be unregistered by calling + GenericXLogUnregister(buffer). In this case, the changes + made to that particular page image copy will be discarded. + + + + + + Generic xlog assumes that pages are using standard layout. I.e., all + information between pd_lower and pd_upper will be discarded. + + + + + + The maximum number of buffers that can be simultaneously registered + for a generic xlog is MAX_GENERIC_XLOG_PAGES. An error will + be thrown if this limit is exceeded. + + + + + Since you modify copies of page images, GenericXLogStart() + does not start a critical section. Thus, you can do memory allocation, + error throwing, etc. between GenericXLogStart() and + GenericXLogFinish(). The actual critical section is present + inside GenericXLogFinish(). + + + + + GenericXLogFinish() takes care of marking buffers as dirty + and setting their LSNs. You do not need to do this explicitly. + + + + + For unlogged relations, everything works the same except there is no + WAL record produced. Thus, you typically do not need to do any explicit + checks for unlogged relations. + + + + + If a registered buffer is not new, the generic xlog record contains + a delta between the old and the new page images. This delta is produced + using per byte comparison. The current delta mechanism is not effective + for moving data within a page and may be improved in the future. + + + + + The generic xlog redo function will acquire exclusive locks to buffers + in the same order as they were registered. After redoing all changes, + the locks will be released in the same order. + + + + + diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml index 7e82cdc3b12..0346d367e5d 100644 --- a/doc/src/sgml/postgres.sgml +++ b/doc/src/sgml/postgres.sgml @@ -247,6 +247,7 @@ &custom-scan; &geqo; &indexam; + &generic-wal; &gist; &spgist; &gin; -- cgit v1.2.3