Re: Hot Standby conflict resolution handling - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Hot Standby conflict resolution handling
Date
Msg-id 20121229192345.GY16126@tamriel.snowman.net
Whole thread Raw
In response to Re: Hot Standby conflict resolution handling  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Responses Re: Hot Standby conflict resolution handling  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
List pgsql-hackers
Pavan,

* Pavan Deolasee (pavan.deolasee@gmail.com) wrote:
> On Tue, Dec 4, 2012 at 6:01 PM, Pavan Deolasee <pavan.deolasee@gmail.com>wrote:
> > Thanks Andres. I also read the original thread and I now understand why we
> > are using FATAL here, at least until we have a better solution. Obviously
> > the connection reset is no good either because as someone commented in the
> > original discussion, I thought that I'm seeing a server crash while it was
> > not.
>
> How about attached comment to be added at the appropriate place ? I've
> extracted this mostly from Tom's explanation in the original thread.

I was hoping to see an update to the actual error messages returned in
this patch..  I agree that it's good to add the comments but that
doesn't do anything to help the user out in this case.

Regarding the actual comment, here's the wording that I'd use:

-----------------------
If we are in DoingCommandRead state, we can't use ereport(ERROR)
because we can't long jumps in this state.  If we attempt to
longjmps in this state, we not only risk breaking protocol at
our level, but also risk leaving openssl in an inconsistent
state, either violating the ssl protocol or having its internal
state trashed because it was interrupted while in the middle of
changing that state.

Currently, the only option is to promote ERROR to FATAL until
we figure out a way to handle errors more effectively while in
this state.
-----------------------

If you agree with that wording update, can you update the patch?
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Next
From: Peter Geoghegan
Date:
Subject: Re: enhanced error fields