Re: archive modules

Nathan Bossart <bossartn@amazon.com>

From: "Bossart, Nathan" <bossartn@amazon.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Fujii Masao <masao.fujii@oss.nttdata.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Stephen Frost <sfrost@snowman.net>, "Magnus Hagander" <magnus@hagander.net>
Date: 2021-11-02T16:39:48Z
Lists: pgsql-hackers
On 11/2/21, 9:17 AM, "Robert Haas" <robertmhaas@gmail.com> wrote:
> On Tue, Nov 2, 2021 at 12:10 PM Bossart, Nathan <bossartn@amazon.com> wrote:
>> Yes, that seems doable.  My point is that I've intentionally chosen to
>> preload the libraries at the moment so that it's possible to define
>> PGC_POSTMASTER GUCs and to use RegisterBackgroundWorker().  If we
>> think that switching archive modules without restarting is more
>> important, I believe we will need to take on a few restrictions.
>
> I guess I'm failing to understand what the problem is. You can set
> GUCs of the form foo.bar in postgresql.conf anyway, right?

I must not be explaining it well, sorry.  I'm mainly thinking about
the following code snippets.

In guc.c:
        /*
         * Only allow custom PGC_POSTMASTER variables to be created during shared
         * library preload; any later than that, we can't ensure that the value
         * doesn't change after startup.  This is a fatal elog if it happens; just
         * erroring out isn't safe because we don't know what the calling loadable
         * module might already have hooked into.
         */
        if (context == PGC_POSTMASTER &&
                !process_shared_preload_libraries_in_progress)
                elog(FATAL, "cannot create PGC_POSTMASTER variables after startup");

In bgworker.c:
        if (!process_shared_preload_libraries_in_progress &&
                strcmp(worker->bgw_library_name, "postgres") != 0)
        {
                if (!IsUnderPostmaster)
                        ereport(LOG,
                                        (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
                                         errmsg("background worker \"%s\": must be registered in shared_preload_libraries",
                                                        worker->bgw_name)));
                return;
        }

You could still introduce GUCs in _PG_init(), but they couldn't be
defined as PGC_POSTMASTER.  Also, you could still use
RegisterDynamicBackgroundWorker() to register a background worker, but
you couldn't use RegisterBackgroundWorker().  These might be
acceptable restrictions if swapping archive libraries on the fly seems
more important, but I wanted to bring that front and center to make
sure everyone understands the tradeoffs.

It's also entirely possible I'm misunderstanding something here...

Nathan

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.