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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Subject: Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND
Date: 2019-05-14 19:52:04
Message-ID: 26332.1557863524@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)com> writes:
> Attached is a patch that fixes the issue in the bug report.

I do not think this is a very good way to fix it (even assuming
that it works, which I'm unsure of --- in particular, doing this
would alter the order of changes to postmaster.pid, possibly
breaking pg_ctl or other tools that look at that file). The whole
point of commit 57431a911 was to switch to log-collector logging
before we've done anything very interesting, and that would surely
include shmem setup. I'm a bit surprised actually that Peter
didn't move the SysLogger_Start call even further up; in principle
it ought to be safe to do it as soon as we have the data directory
lock file.

It might be better to give up the assertion in PGSharedMemoryNoReAttach,
and just make it work more like PGSharedMemoryDetach, ie "detach if
UsedShmemSegAddr is set, else do nothing". I don't remember for sure,
but if we do that, there might be no functional difference anymore
between those two functions, in which case we might as well merge 'em.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2019-05-14 20:58:20 Re: inconsistent results querying table partitioned by date
Previous Message Yuli Khodorkovskiy 2019-05-14 18:45:09 Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND