Re: Postgres service stops when I kill client backend on Windows

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Ali Akbar <the(dot)apaan(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Dmitry Vasilyev <d(dot)vasilyev(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgres service stops when I kill client backend on Windows
Date: 2015-10-12 05:55:35
Message-ID: CAA4eK1K-r3P9USd8OcwzHFHh4kjUpZSus=iJ7reH=XH5f9cXaA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
fix_syslogger_dangling_shmhandle_v1.patch application/octet-stream 827 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2015-10-12 06:21:26 Re: Parallel Seq Scan
Previous Message Haribabu Kommi 2015-10-12 05:25:52 Re: Parallel Aggregate