Re: archive modules

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: talk to ben <blo.talkto@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Robert Haas <robertmhaas@gmail.com>, "Bossart, Nathan" <bossartn@amazon.com>, David Steele <david@pgmasters.net>, Fujii Masao <masao.fujii@oss.nttdata.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Michael Paquier <michael@paquier.xyz>, Magnus Hagander <magnus@hagander.net>, Stephen Frost <sfrost@snowman.net>
Date: 2022-08-23T17:47:40Z
Lists: pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes:
> I don't know if it makes sense to document this in basic_archive.  On one
> hand, it seems like folks will commonly encounter this behavior with this
> module, so this feels like a natural place for such a note.  But on the
> other hand, this is generic behavior for any library that is dynamically
> loaded in a separate process.

Yeah, I don't think this material is at all specific to basic_archive.
Maybe it could be documented near the relevant views, if it isn't already.

Also, I think the proposed text neglects the case of including the
module in shared_preload_libraries.

			regards, tom lane



Commits

  1. Disallow setting archive_library and archive_command at the same time

  2. Restore archive_command documentation

  3. Doc: improve explanation of when custom GUCs appear in pg_settings.

  4. doc: Add note about re-archiving of same WAL files in docs.

  5. In basic_archive tests, insist on wal_level='replica'.

  6. Allow archiving via loadable modules.

  7. Move the code to archive files via the shell to a separate file.