On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane <tgl@sss.pgh.pa.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