Re: Snapshot management, final
От | Alvaro Herrera |
---|---|
Тема | Re: Snapshot management, final |
Дата | |
Msg-id | 20080512011016.GG5746@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Snapshot management, final (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Snapshot management, final
|
Список | pgsql-patches |
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> 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
В списке pgsql-patches по дате отправления: