Re: Standalone backends run StartupXLOG in an incorrect environment

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Standalone backends run StartupXLOG in an incorrect environment
Дата
Msg-id 3027.1271702060@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Standalone backends run StartupXLOG in an incorrect environment  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Standalone backends run StartupXLOG in an incorrect environment
Список pgsql-hackers
I wrote:
> The point is that a standalone backend will fail to execute recovery
> correctly:
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01297.php

After digging around a bit, it seems like the cleanest solution would be
to move the responsibility for calling StartupXLOG in a standalone
backend into InitPostgres.  At the point where the latter currently has
/* * Initialize local process's access to XLOG, if appropriate.  In * bootstrap case we skip this since StartupXLOG()
wasrun instead. */if (!bootstrap)    (void) RecoveryInProgress();
 

we'd add a couple of lines to call StartupXLOG if !IsUnderPostmaster,
and then remove the call from postgres.c.  I haven't tested this yet
but it looks like the correct state has been set up at that point.
Anyone see any obvious holes in the idea?
        regards, tom lane


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during Hot Standby by avoiding loop
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Thoughts on pg_hba.conf rejection