mirror of
https://github.com/postgres/postgres.git
synced 2025-12-21 05:21:08 +03:00
09d9800e52
Previously, we had consecutive, very short chapters called "Generic WAL" and "Custom WAL Resource Managers," explaining different approaches to the same problem. Merge them into a single chapter. Explain most of the differences between the approaches in the chapter's introductory text, rather than in the individual sections. Discussion: http://postgr.es/m/46ac50c1-6b2a-404f-a683-b67af6ab56e9@eisentraut.org
33 lines
1.2 KiB
Plaintext
33 lines
1.2 KiB
Plaintext
<!-- doc/src/sgml/wal-for-extensions.sgml -->
|
|
|
|
<chapter id="wal-for-extensions">
|
|
<title>Write Ahead Logging for Extensions</title>
|
|
|
|
<para>
|
|
Certain extensions, principally extensions that implement custom access
|
|
methods, may need to perform write-ahead logging in order to ensure
|
|
crash-safety. <productname>PostgreSQL</productname> provides two ways
|
|
for extensions to achieve this goal.
|
|
</para>
|
|
|
|
<para>
|
|
First, extensions can choose to use <link linkend="generic-wal">generic
|
|
WAL</link>, a special type of WAL record which describes changes to pages
|
|
in a generic way. This method is simple to implement and does not require
|
|
that an extension library be loaded in order to apply the records. However,
|
|
generic WAL records will be ignored when performing logical decoding.
|
|
</para>
|
|
|
|
<para>
|
|
Second, extensions can choose to use a <link linkend="custom-rmgr">custom
|
|
resource manager</link>. This method is more flexible, supports logical
|
|
decoding, and can sometimes generate much smaller write-ahead log records
|
|
than would be possible with generic WAL. However, it is more complex for an
|
|
extension to implement.
|
|
</para>
|
|
|
|
&generic-wal;
|
|
&custom-rmgr;
|
|
|
|
</chapter>
|