On 2014-06-03 23:37:28 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > I thought the reason why this hasn't been implemented before now is
> > that sending an ErrorResponse to the client will result in a loss of
> > protocol sync.
>
> Hmm ... you are right that this isn't as simple as an ereport(ERROR),
> but I'm not sure it's impossible. We could for instance put the backend
> into skip-till-Sync state so that it effectively ignored the next command
> message. Causing that to happen might be impracticably messy, though.
Isn't another problem here that we're reading from the client, possibly
nested inside openssl? So we can't just longjmp out without possibly
destroying openssl's internal state?
I think that's solveable by first returning from openssl, signalling a
short read, and only *then* jumping out. I remember making something
like that work in a POC patch at least... But it's been a couple of years.
> I'm not sure whether cancel-transaction behavior is enough better than
> cancel-session to warrant extra effort here.
I don't think idle_in_transaction_timeout is worth this, but if we could
implement it we could finally have recovery conflicts against idle in
txn sessions not use FATAL...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
