Re: Re: [COMMITTERS] pgsql: Perform only one ReadControlFile() during startup.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Perform only one ReadControlFile() during startup.
Date: 2017-09-18 19:33:29
Message-ID: 25370.1505763209@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-09-18 12:16:42 -0400, Robert Haas wrote:
>> I don't understand what you're talking about here.

> I often see a backend crash, psql reacting to that crash by
> reconnecting, successfully establish a new connection, just to be kicked
> off by postmaster that does the crash restart cycle. I've not yet
> figured out when exactly this happens and when not.

It seems like this must indicate that psql sees the connection drop
significantly before the postmaster gets SIGCHLD. Which is weird, but
if you have core dumps enabled, maybe your kernel is doing something like
(1) close files, (2) dump core, (3) exit process (resulting in SIGCHLD)?

I don't think I've ever seen this myself. Peculiarity of some kernels,
perhaps.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-09-18 20:01:21 pgsql: Make ExplainOpenGroup and ExplainCloseGroup public.
Previous Message Tom Lane 2017-09-18 19:21:35 pgsql: Make DatumGetFoo/PG_GETARG_FOO/PG_RETURN_FOO macro names more co

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-09-18 20:03:40 Re: [PATCH] Make ExplainBeginGroup()/ExplainEndGroup() public.
Previous Message Tom Lane 2017-09-18 19:26:36 Re: PG_GETARG_GISTENTRY?