Re: parallelizing the archiver - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: parallelizing the archiver
Date
Msg-id 0C272F63-37B1-43FC-AB5E-04A68ED4335C@amazon.com
Whole thread Raw
In response to Re: parallelizing the archiver  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: parallelizing the archiver  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 10/25/21, 10:50 AM, "Bossart, Nathan" <bossartn@amazon.com> wrote:
> On 10/25/21, 10:18 AM, "Robert Haas" <robertmhaas@gmail.com> wrote:
>> On Mon, Oct 25, 2021 at 1:14 PM Bossart, Nathan <bossartn@amazon.com> wrote:
>>> IIUC this would mean that archive modules that need to define GUCs or
>>> register background workers would have to separately define a
>>> _PG_init() and be loaded via shared_preload_libraries in addition to
>>> archive_library.  That doesn't seem too terrible to me, but it was
>>> something I was trying to avoid.
>>
>> Hmm. That doesn't seem like a terrible goal, but I think we should try
>> to find some way of achieving it that looks tidier than this does.
>
> We could just treat archive_library as if it is tacked onto the
> shared_preload_libraries list.  I think I can make that look
> relatively tidy.

Alright, here is an attempt at that.  With this revision, archive
libraries are preloaded (and _PG_init() is called), and the archiver
is responsible for calling _PG_archive_module_init() to get the
callbacks.  I've also removed the GUC check hooks as previously
discussed.

Nathan


Attachment

pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Next
From: Tom Lane
Date:
Subject: Re: Assorted improvements in pg_dump