Re: parallelizing the archiver

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: parallelizing the archiver
Дата
Msg-id 8253328E-9E61-437E-8F0C-B419741F717C@amazon.com
обсуждение исходный текст
Ответ на Re: parallelizing the archiver  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: parallelizing the archiver  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 10/25/21, 10:02 AM, "Robert Haas" <robertmhaas@gmail.com> wrote:
> I don't see why this patch should need to make any changes to
> internal_load_library(), PostmasterMain(), SubPostmasterMain(), or any
> other central point of control, and I don't think it should.
> pgarch_archiveXlog() can just load the library at the time it's
> needed. That way it only gets loaded in the archiver process, and the
> required changes are much more localized. Like instead of asserting
> that the functions are initialized, just
> load_external_function(libname, "_PG_archive_module_init") and call it
> if they aren't.

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.

> I think the attempt in check_archive_command()/check_archive_library()
> to force exactly one of those two to be set is not going to work well
> and should be removed. In general, GUCs whose legal values depend on
> the values of other GUCs don't end up working out well. I think what
> should happen instead is that if archive_library=shell then
> archive_command does whatever it does; otherwise archive_command is
> without effect.

I'm fine with this approach.  I'll go this route in the next revision.

Nathan


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump versus ancient server versions
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pg_dump versus ancient server versions