Skip site navigation (1) Skip section navigation (2)

Re: Hot Standby conflict resolution handling

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>,Stephen Frost <sfrost(at)snowman(dot)net>,Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby conflict resolution handling
Date: 2013-01-17 10:47:44
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On 2013-01-17 01:38:31 -0500, Tom Lane wrote:
> But having said that ... are we sure this code is not actually broken?
> 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.

You're absolutely right.

ISTM, to fix it we would have to either provide a COMERROR like facility
for FATAL errors or just remove the requirement of raising an error
exactly there.
If I remember what I tried before correctly the latter seems to involve
setting openssl into nonblocking mode and check for the saved error in
the EINTR loop in be-secure and re-raise the error from there.

Do we want to backport either - there hasn't been any report that I
could link to it right now, but on the other hand it could possibly
cause rather ugly problems (data leakage, segfaults, code execution
aren't all that improbable)?


Andres Freund

 Andres Freund	         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

pgsql-hackers by date

Next:From: Andres FreundDate: 2013-01-17 10:54:00
Subject: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave
Previous:From: Magnus HaganderDate: 2013-01-17 10:28:15
Subject: Re: Multiple --table options for other commands

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group