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

From Pavan Deolasee
Subject Re: Hot Standby conflict resolution handling
Date
Msg-id CABOikdOcMSdC=L83ScqwkdctMcqRYwqnkJetFHA5=Vq-Up_KqA@mail.gmail.com
Whole thread Raw
In response to Re: Hot Standby conflict resolution handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Hot Standby conflict resolution handling
List pgsql-hackers


On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

But having said that ... are we sure this code is not actually broken?

I'm not.
 
ISTM that if we dare not interrupt for fear of confusing OpenSSL, we
cannot safely attempt to send an error message to the client either;
but ereport(FATAL) will try exactly that.

I thought since FATAL will force the backend to exit, we don't care much about corrupted OpenSSL state. I even thought that's why we raise ERROR to FATAL so that the backend can start in a clean state. But clearly I'm missing a point here because you don't think that way.

Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: CF3+4 (was Re: Parallel query execution)
Next
From: Simon Riggs
Date:
Subject: Re: Removing PD_ALL_VISIBLE