Re: [PATCH] V3: Idle in transaction cancellation

On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm handwaving there --- I think probably the
> first cut should just discard errors after the first, and see how
> well that works in practice.

Seems reasonable.

>> Another thing I don't quite understand is - at what point does the
>> protocol allow us to emit an error?
>
> Basically, you can send an error in response to a query.

What about some other message that's not a query?

>> Suppose that the transaction gets
>> cancelled due to a conflict with recovery while we're
>> DoingCommandRead, and then the user now sends us "SELCT 2+2".  Are we
>> going to send them back both errors now, or just one of them?  Which
>> one?
>
> You can only send one, and in that situation you probably want the
> cancellation to be reported.

What about an elog or ereport with severity < ERROR? Surely there
must at least be provision for multiple non-error messages per
transaction.

> FWIW, I'm not too worried about preserving the existing
> recovery-conflict behavior, as I think the odds are at least ten to one
> that that code is broken when you look closely enough.  I do like the
> idea that this patch would provide a better-thought-out framework for
> handling the conflict case.

We already have pg_terminate_backend() and pg_cancel_backend(). Are
you imagining a general mechanism like pg_rollback_backend()?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company