On Tue, Oct 27, 2015 at 6:29 AM, Rajeev rastogi <rajeev.rast...@huawei.com> wrote: > On 23 October 2015 01:58, Robert Haas [mailto:robertmh...@gmail.com] Wrote: >>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. > > Agree. > >>Here's a version with that removed and some changes to the comments. > > Thanks for changing. > >>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. > > Actually in this case client is not waiting for the response from the server > rather it is waiting for new command from user. > So even though server has sent the response to client, client is not able to > receive. > Once client receives the next command to execute, by the time connection has > terminated from server side and hence it comes out with the above message > (i.e. server closed the connection...) > > Though I am also in favor of providing some error message to client. But > with the current infrastructure, I don’t think there is any way to pass this > error message to client [This error has happened without involvement of the > client side]. > > Comments?
Hmm. ProcessInterrupts() signals some FATAL errors while the connection is idle, and rumor has it that that works: the client doesn't immediately read the FATAL error, but the next time it sends a query, it tries to read from the connection and sees the FATAL error at that time. I wonder why that's not working here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
