On Пн, 2015-10-12 at 11:25 +0530, Amit Kapila wrote:
On Sun, Oct 11, 2015 at 9:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Magnus Hagander <magnus@hagander.net> writes: > > On Sun, Oct 11, 2015 at 5:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> I'm a bit suspicious that we may have leaked a handle to the shared > >> memory block someplace, for example. That would explain why this > >> symptom is visible now when it was not in 2009. Or maybe it's dependent > >> on some feature that we didn't test back then --- for instance, if > >> the logging collector is in use, could it have inherited a handle and > >> not closed it? > > > Even if we leaked it, it should go away when the other processes died. > > I'm fairly certain that we do not kill/restart the logging collector > during a database restart (because it's impossible to reproduce the > original stderr destination if we do).
True and it seems this is the reason for issue we are discussing here.
The reason why this happens is that during creation of shared memory
(PGSharedMemoryCreate()), we duplicate the handle such that it
become inheritable by all child processes. Then during fork
(syslogger_forkexec()->postmaster_forkexec()->internal_forkexec) we
always inherit the handles which causes syslogger to get a copy of
shared memory handle which it neither uses and nor closes it.
I could easily reproduce the issue if logging collector is on and even if
we try to increase the loop count or sleep time in PGSharedMemoryCreate(),
it doesn't change the situation as the syslogger has a valid handle to
shared memory. One way to fix is to just close the shared memory handle
in sys logger as we are not going to need it and attached patch which does
this fixes the issue for me. Another invasive fix in case we want to
retain shared memory handle for some purpose (future requirement) could
be to send some signal to syslogger in restart path so that it can release
