On Thu, Mar 19, 2015 at 08:43:52PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > On Thu, Mar 19, 2015 at 06:59:20PM -0300, Alvaro Herrera wrote: > >> I don't understand why aren't interrupts held until after the commit is > >> done -- including across the mentioned ereports. > > > Uh, I think Robert was thinking of pre-commit triggers at the top of > > CommitTransaction() that might take a long time and we might want to > > cancel. > > Yeah, that's a good point. So really the only way to make this work as > requested is to have some cooperation between xact.c and postgres.c, > so that the hold taken midway through CommitTransaction is kept until > we reach the idle point. > > The attached is only very lightly tested but shows what we probably > would need for this. It's a bit messy in that the API for > CommitTransactionCommand leaves it unspecified whether interrupts are > held at exit; I'm not sure if it's useful or feasible to be more precise.
Oh, I see what you are saying, and why a global variable will not work. I thought all paths reset the cancel state when the returned from a commit, but it seems there are many places that don't do reset, so you have to pass a flag down into CommitTransaction() to control that --- makes sense. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
