Hello, Amit!
On Пн, 2015-10-12 at 11:25 +0530, Amit Kapila wrote:
> On Sun, Oct 11, 2015 at 9:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > > On Sun, Oct 11, 2015 at 5:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
> the shared memory handle.
>
>
>
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
Specified patch with "ifdef WIN32" is working for me. Maybe it’s
necessary to check open handlers from replication for example?
--------------
Dmitry Vasilyev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company