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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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


Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2013-01-17 06:52:53 Re: CF3+4
Previous Message Tom Lane 2013-01-17 06:06:13 Re: CF3+4