Re: [HACKERS] Dangling Client Backend Process

2015-11-12 Thread Robert Haas
On Wed, Nov 11, 2015 at 1:55 AM, Michael Paquier wrote: > On Wed, Nov 4, 2015 at 2:18 AM, Robert Haas wrote: >> The second conclusion does not appear to be correct. parseInput() >> will call pqParseInput3() or pqParseInput2(), either of which will >> handle an error as if it were a notice - i.e.

Re: [HACKERS] Dangling Client Backend Process

2015-11-10 Thread Michael Paquier
On Wed, Nov 4, 2015 at 2:18 AM, Robert Haas wrote: > > The second conclusion does not appear to be correct. parseInput() > will call pqParseInput3() or pqParseInput2(), either of which will > handle an error as if it were a notice - i.e. by printing it out. Right per pqGetErrorNotice3 when the co

Re: [HACKERS] Dangling Client Backend Process

2015-11-03 Thread Robert Haas
On Fri, Oct 30, 2015 at 11:03 AM, Andres Freund wrote: > On 2015-10-30 10:57:45 -0400, Tom Lane wrote: >> Andres Freund writes: >> > adding a parseInput(conn) into the loop yields the expected >> > FATAL: 57P01: terminating connection due to unexpected postmaster exit >> > Is there really any re

Re: [HACKERS] Dangling Client Backend Process

2015-11-02 Thread Rajeev rastogi
On 30 October 2015 20:33, Andres Freund Wrote: >On 2015-10-30 10:57:45 -0400, Tom Lane wrote: >> Andres Freund writes: >> > adding a parseInput(conn) into the loop yields the expected >> > FATAL: 57P01: terminating connection due to unexpected postmaster >> > exit Is there really any reason not t

Re: [HACKERS] Dangling Client Backend Process

2015-10-30 Thread Andres Freund
On 2015-10-30 10:57:45 -0400, Tom Lane wrote: > Andres Freund writes: > > adding a parseInput(conn) into the loop yields the expected > > FATAL: 57P01: terminating connection due to unexpected postmaster exit > > Is there really any reason not to do that? > > Might work, but it probably needs so

Re: [HACKERS] Dangling Client Backend Process

2015-10-30 Thread Tom Lane
Andres Freund writes: > adding a parseInput(conn) into the loop yields the expected > FATAL: 57P01: terminating connection due to unexpected postmaster exit > Is there really any reason not to do that? Might work, but it probably needs some study: (a) is it safe (b) is this the right place / are

Re: [HACKERS] Dangling Client Backend Process

2015-10-30 Thread Andres Freund
On 2015-10-30 09:48:33 -0400, Tom Lane wrote: > Robert Haas writes: > > 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

Re: [HACKERS] Dangling Client Backend Process

2015-10-30 Thread Tom Lane
Robert Haas writes: > 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 > a

Re: [HACKERS] Dangling Client Backend Process

2015-10-30 Thread Robert Haas
On Tue, Oct 27, 2015 at 6:29 AM, Rajeev rastogi 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 t

Re: [HACKERS] Dangling Client Backend Process

2015-10-26 Thread Rajeev rastogi
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 >basical

Re: [HACKERS] Dangling Client Backend Process

2015-10-22 Thread Robert Haas
On Tue, Oct 20, 2015 at 11:42 PM, Rajeev rastogi 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 WaitL

Re: [HACKERS] Dangling Client Backend Process

2015-10-20 Thread Rajeev rastogi
On 20 October 2015 23:34, Robert Haas [mailto:robertmh...@gmail.com] Wrote: >On Tue, Oct 20, 2015 at 12:11 PM, Alvaro Herrera > wrote: >> Robert Haas wrote: >>> I don't think that proc_exit(1) is the right way to exit here. It's >>> not very friendly to exit without at least attempting to give th

Re: [HACKERS] Dangling Client Backend Process

2015-10-20 Thread Alvaro Herrera
Robert Haas wrote: > On Tue, Oct 20, 2015 at 12:11 PM, Alvaro Herrera > wrote: > > Agreed, but I don't think "shutdown" is the right word to use here -- > > that makes it sound like it was orderly. Perhaps "crash"? > > Well, that's a little speculative. "due to unexpected postmaster exit"? WF

Re: [HACKERS] Dangling Client Backend Process

2015-10-20 Thread Robert Haas
On Tue, Oct 20, 2015 at 12:11 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> I don't think that proc_exit(1) is the right way to exit here. It's >> not very friendly to exit without at least attempting to give the >> client a clue about what has gone wrong. I suggest something like >> this: >

Re: [HACKERS] Dangling Client Backend Process

2015-10-20 Thread Alvaro Herrera
Robert Haas wrote: > I don't think that proc_exit(1) is the right way to exit here. It's > not very friendly to exit without at least attempting to give the > client a clue about what has gone wrong. I suggest something like > this: > > ereport(FATAL, > (errcode(

Re: [HACKERS] Dangling Client Backend Process

2015-10-20 Thread Robert Haas
On Tue, Oct 20, 2015 at 12:48 AM, Rajeev rastogi wrote: > On 19 October 2015 21:37, Robert Haas [mailto:robertmh...@gmail.com] Wrote: > >>On Sat, Oct 17, 2015 at 4:52 PM, Alvaro Herrera >> wrote: >>> Andres Freund wrote: On 2015-10-14 17:33:01 +0900, Kyotaro HORIGUCHI wrote: > If I reca

Re: [HACKERS] Dangling Client Backend Process

2015-10-19 Thread Rajeev rastogi
On 19 October 2015 21:37, Robert Haas [mailto:robertmh...@gmail.com] Wrote: >On Sat, Oct 17, 2015 at 4:52 PM, Alvaro Herrera > wrote: >> Andres Freund wrote: >>> On 2015-10-14 17:33:01 +0900, Kyotaro HORIGUCHI wrote: >>> > If I recall correctly, he concerned about killing the backends >>> > runni

Re: [HACKERS] Dangling Client Backend Process

2015-10-19 Thread Robert Haas
On Sat, Oct 17, 2015 at 4:52 PM, Alvaro Herrera wrote: > Andres Freund wrote: >> On 2015-10-14 17:33:01 +0900, Kyotaro HORIGUCHI wrote: >> > If I recall correctly, he concerned about killing the backends >> > running transactions which could be saved. I have a sympathy with >> > the opinion. >> >>

Re: [HACKERS] Dangling Client Backend Process

2015-10-17 Thread Alvaro Herrera
Andres Freund wrote: > On 2015-10-14 17:33:01 +0900, Kyotaro HORIGUCHI wrote: > > If I recall correctly, he concerned about killing the backends > > running transactions which could be saved. I have a sympathy with > > the opinion. > > I still don't. Leaving backends alive after postmaster has die

Re: [HACKERS] Dangling Client Backend Process

2015-10-16 Thread Amit Kapila
On Fri, Oct 16, 2015 at 3:34 PM, Rajeev rastogi wrote: > > > Yes it will be really helpful to know the earlier reason for "not making > backend exit on postmaster death". > Please let me know if there is any thread, which I can refer to find the > same. > > IMHO there could be below major issues,

Re: [HACKERS] Dangling Client Backend Process

2015-10-16 Thread Rajeev rastogi
On 14 October 2015 14:03, Kyotaro HORIGUCHI: >Subject: Re: [HACKERS] Dangling Client Backend Process > >At Wed, 14 Oct 2015 11:08:37 +0530, Amit Kapila >wrote in > >> On Tue, Oct 13, 2015 at 3:54 PM, Rajeev rastogi >> >> wrote: >> > If we add the even

Re: [HACKERS] Dangling Client Backend Process

2015-10-14 Thread Andres Freund
On 2015-10-14 17:33:01 +0900, Kyotaro HORIGUCHI wrote: > If I recall correctly, he concerned about killing the backends > running transactions which could be saved. I have a sympathy with > the opinion. I still don't. Leaving backends alive after postmaster has died prevents the auto-restart mecha

Re: [HACKERS] Dangling Client Backend Process

2015-10-14 Thread Kyotaro HORIGUCHI
At Wed, 14 Oct 2015 11:08:37 +0530, Amit Kapila wrote in > On Tue, Oct 13, 2015 at 3:54 PM, Rajeev rastogi > wrote: > > If we add the event WL_POSTMASTER_DEATH also, client backend process > > handling will become same as other backend process. So postmaster death can > > be detected in the sam

Re: [HACKERS] Dangling Client Backend Process

2015-10-13 Thread Amit Kapila
On Tue, Oct 13, 2015 at 3:54 PM, Rajeev rastogi wrote: > On 12th October 2015 20:45, Rajeev Rastogi Wrote: > > > > >>> I observed one strange behavior today that if postmaster process gets > crashed/killed, then it kill all background processes but not the client > backend process. > > > > >> Thi

Re: [HACKERS] Dangling Client Backend Process

2015-10-13 Thread Rajeev rastogi
On 12th October 2015 20:45, Rajeev Rastogi Wrote: >>> I observed one strange behavior today that if postmaster process gets >>> crashed/killed, then it kill all background processes but not the client >>> backend process. >> This is a known behaviour and there was some discussion on this >> top

Re: [HACKERS] Dangling Client Backend Process

2015-10-12 Thread Rajeev rastogi
On 10 October 2015 20:45, Amit Kapila Wrote: >> I observed one strange behavior today that if postmaster process gets >> crashed/killed, then it kill all background processes but not the client >> backend process. > This is a known behaviour and there was some discussion on this > topic [1] pre

Re: [HACKERS] Dangling Client Backend Process

2015-10-10 Thread Amit Kapila
On Sat, Oct 10, 2015 at 3:42 PM, Rajeev rastogi wrote: > I observed one strange behavior today that if postmaster process gets > crashed/killed, then it kill all background processes but not the client > backend process. > > Moreover it is also allowed to execute query on the connected client > s

[HACKERS] Dangling Client Backend Process

2015-10-10 Thread Rajeev rastogi
I observed one strange behavior today that if postmaster process gets crashed/killed, then it kill all background processes but not the client backend process. Moreover it is also allowed to execute query on the connected client session without any other background process. But If I try to execu