Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND
Date
Msg-id 31437.1557982294@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND  (Michael Paquier <michael@paquier.xyz>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND
Next
From: PG Bug reporting form
Date:
Subject: BUG #15808: ERROR: subtransaction logged without previous top-level txn record (SQLSTATE XX000)