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
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 |
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? |