Re: Dangling Client Backend Process

On Tue, Oct 20, 2015 at 11:42 PM, Rajeev rastogi
<rajeev(dot)rastogi(at)huawei(dot)com> wrote:
> Agreed. Attached is the patch with changes.

Well, I'm not buying this extra PostmasterIsAlive() call on every pass
through the main loop. That seems more expensive than we can really
justify. Checking this when we're already calling WaitLatchOrSocket is
basically free, but the other part is not.

Here's a version with that removed and some changes to the comments.
I still don't think this is quite working right, though, because
here's what happened when I killed the postmaster:

rhaas=# select 1;
?column?
----------
1
(1 row)

rhaas=# \watch
Watch every 2s Thu Oct 22 16:24:10 2015

?column?
----------
1
(1 row)

Watch every 2s Thu Oct 22 16:24:12 2015

?column?
----------
1
(1 row)

Watch every 2s Thu Oct 22 16:24:14 2015

?column?
----------
1
(1 row)

Watch every 2s Thu Oct 22 16:24:16 2015

?column?
----------
1
(1 row)

server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Note that the error message doesn't actually show up on the client (it
did show up in the log). I guess that may be inevitable if we're
blocked in secure_write(), but if we're in secure_read() maybe it
should work? I haven't investigated why it doesn't.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company