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

Re: Hot Standby conflict resolution handling

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Andres Freund <andres(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby conflict resolution handling
Date: 2013-01-17 06:38:31
Message-ID: 29354.1358404711@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> writes:
> Sorry for nitpicking, but "we can't long jumps" made me cringe.

Agreed :-(

> Here's a slightly more condensed version:

I find this still not quite right, because where it's placed, it applies
to both the DoingCommandRead and !DoingCommandRead branches of the
if/else statement.  The wording would be okay if placed inside the first
if branch, but I think visually that would look ugly.  I'm inclined to
suggest wording it like

	* If we're in DoingCommandRead state, we can't use ereport(ERROR),
	* because any longjmp would risk interrupting OpenSSL operations
	* and thus confusing that library and/or violating wire protocol.

plus your second para as-is.

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.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Craig RingerDate: 2013-01-17 06:52:53
Subject: Re: CF3+4
Previous:From: Tom LaneDate: 2013-01-17 06:06:13
Subject: Re: CF3+4

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