|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> writes:
> Sorry for nitpicking, but "we can't long jumps" made me cringe.
> 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
|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|