Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND
Дата
Msg-id 31437.1557982294@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-bugs
Michael Paquier <michael@paquier.xyz> writes:
> On Thu, May 16, 2019 at 12:56:17PM +0900, Michael Paquier wrote:
>> The test is able to pass, but we have a race condition between the
>> moment the backend file gets saved and the moment we allow it to be
>> read.   I have not spent much time checking the stack between
>> InitializeMaxBackends() and RemovePgTempFiles() in postmaster.c, but
>> 57431a9 triggers the failure.

> Oh, I think I got it.  The issue is that we call RemovePgTempFiles()
> after starting the syslogger.  This cannot be run with other processes
> running in parallel, and with EXEC_BACKEND there is the extra case
> where we have a pgsql_tmp/ at the root of the data folder, so the
> syslogger complains on that.  By making RemovePgTempFiles() happen
> before starting the syslogger, then the test complains again about the
> assertion without my previous patch applied of course.  With the patch
> applied, I get no complains.

Hm, should we separate the cleanup of the root pgsql_tmp/ from the rest of
what RemovePgTempFiles does?  I'm still feeling like we should be trying
to launch the syslogger as soon as possible.

            regards, tom lane



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15808: ERROR: subtransaction logged without previous top-level txn record (SQLSTATE XX000)