On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
