Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Shouldn't UnregisterSnapshot insist that s_level be equal to current > >> xact nest level? > > > It can't check that; consider > > > begin; > > savepoint foo; > > declare cur cursor for select (1), (2), (3); > > savepoint bar; > > close cur; > > commit; > > Hmm ... but that "close" can't unregister the snapshot immediately, > because you'd lose if the 2nd savepoint gets rolled back, no? Is the > handling of this case even correct at the moment?
No, CLOSE is not rolled back: alvherre=# begin; BEGIN alvherre=# savepoint foo; SAVEPOINT alvherre=# declare cur cursor for select (1), (2), (3); DECLARE CURSOR alvherre=# savepoint bar; SAVEPOINT alvherre=# close cur; CLOSE CURSOR alvherre=# rollback to bar; ROLLBACK alvherre=# fetch all from cur; ERREUR: le curseur « cur » n'existe pas Maybe this is possible to fix, but again I think it's outside the scope of this patch. > ISTM correct handling of this example would require that the "close" > not really discard the snap until commit. Then, given proper ordering > of the cleanup operations at commit, you might be able to still have the > cross-check about s_level in UnregisterSnapshot. (IOW, maybe having > snapshot cleanup be late in the commit sequence wasn't such a good > choice...) Right -- I'll move them earlier. I don't think it's trivial to fix the un-rollback-ability of CLOSE however. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
