Re: parallelizing the archiver - Mailing list pgsql-hackers

From Robert Haas
Subject Re: parallelizing the archiver
Date
Msg-id CA+TgmobV4dsx5oWZ5izfcGVM3Q0Vq2Byr=_Oq4quqdhYgQvW=A@mail.gmail.com
Whole thread Raw
In response to Re: parallelizing the archiver  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: parallelizing the archiver  ("Bossart, Nathan" <bossartn@amazon.com>)
List pgsql-hackers
On Fri, Oct 22, 2021 at 1:42 PM Bossart, Nathan <bossartn@amazon.com> wrote:
> Another approach would be to add a new initialization function (e.g.,
> PG_archive_init()) that would be used if the library is being loaded
> from archive_library.  Like before, you can use the library for both
> shared_preload_libraries and archive_library, but your initialization
> logic would be expected to go in separate functions.  However, there
> still wouldn't be anything forcing that.  A library could still break
> the rules and do everything in _PG_init() and be loaded via
> shared_preload_libraries.

I was imagining something like what logical decoding does. In that
case, you make a _PG_output_plugin_init function and it returns a
table of callbacks. Then the core code invokes those callbacks at the
appropriate times.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump versus ancient server versions
Next
From: Tom Lane
Date:
Subject: Re: pg_dump versus ancient server versions