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.
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
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
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
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
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
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
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
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
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
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
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
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
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:
>
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(
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
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
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.
>>
>>
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
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,
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
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
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
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
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
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
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
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
28 matches
Mail list logo