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
|
Список | 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 по дате отправления: