Thread: ROLLBACK TO SAVEPOINT
The note at the end of; http://www.postgresql.org/docs/8.4/static/sql-savepoint.html Lead us to believe that if you roll back to the same savepoint name twice in a row, that you might start walking back through the savepoints. I guess I missed the note on ROLLBACK TO SAVEPOINT that that is not how it works. Here is the section: SQL requires a savepoint to be destroyed automatically when another savepoint with the same name is established. In PostgreSQL, the old savepoint is kept, though only the more recent one will be used when rolling back or releasing. (Releasing the newer savepoint will cause the older one to again become accessible to ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT.) Otherwise, SAVEPOINT is fully SQL conforming. I think it could be improved by also communicating: Rollback to a savepoint never releases it; you can safely repeat ROLLBACK TO SAVEPOINT statements without unwinding the transaction, even if you are re-using savepoint names. Well, maybe no-one else will ever have the misconception I did, but there it is. Sam.
On May 25, 2010, at 6:08 , Sam Vilain wrote: > http://www.postgresql.org/docs/8.4/static/sql-savepoint.html > > Lead us to believe that if you roll back to the same savepoint name > twice in a row, that you might start walking back through the > savepoints. I guess I missed the note on ROLLBACK TO SAVEPOINT that > that is not how it works. > > Here is the section: > > SQL requires a savepoint to be destroyed automatically when another > savepoint with the same name is established. In PostgreSQL, the old > savepoint is kept, though only the more recent one will be used when > rolling back or releasing. (Releasing the newer savepoint will cause the > older one to again become accessible to ROLLBACK TO SAVEPOINT and > RELEASE SAVEPOINT.) Otherwise, SAVEPOINT is fully SQL conforming. I'm confused. The sentence in brackets "Releasing the newer savepoint will cause the older one to again become accessibleto ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT" implies that you *will* walk backwards through all the savepointsnamed "a" if you repeatedly issue "ROLLBACK TO SAVEPOINT a", no? If that is not how it actually works, then thiswhole paragraph is wrong, I'd say. best regards, Florian Pflug
On 25/05/10 13:03, Florian Pflug wrote: > On May 25, 2010, at 6:08 , Sam Vilain wrote: >> http://www.postgresql.org/docs/8.4/static/sql-savepoint.html >> >> Lead us to believe that if you roll back to the same savepoint name >> twice in a row, that you might start walking back through the >> savepoints. I guess I missed the note on ROLLBACK TO SAVEPOINT that >> that is not how it works. >> >> Here is the section: >> >> SQL requires a savepoint to be destroyed automatically when another >> savepoint with the same name is established. In PostgreSQL, the old >> savepoint is kept, though only the more recent one will be used when >> rolling back or releasing. (Releasing the newer savepoint will cause the >> older one to again become accessible to ROLLBACK TO SAVEPOINT and >> RELEASE SAVEPOINT.) Otherwise, SAVEPOINT is fully SQL conforming. > > I'm confused. The sentence in brackets "Releasing the newer savepoint will cause the older one to again become accessibleto ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT" implies that you *will* walk backwards through all the savepointsnamed "a" if you repeatedly issue "ROLLBACK TO SAVEPOINT a", no? If that is not how it actually works, then thiswhole paragraph is wrong, I'd say. Releasing the newer savepoint will cause the older one to again become accessible, as the doc says, but rolling back to a savepoint does not implicitly release it. You'll have to use RELEASE SAVEPOINT for that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On May 25, 2010, at 12:18 , Heikki Linnakangas wrote: > On 25/05/10 13:03, Florian Pflug wrote: >> On May 25, 2010, at 6:08 , Sam Vilain wrote: >>> http://www.postgresql.org/docs/8.4/static/sql-savepoint.html >>> >>> Lead us to believe that if you roll back to the same savepoint name >>> twice in a row, that you might start walking back through the >>> savepoints. I guess I missed the note on ROLLBACK TO SAVEPOINT that >>> that is not how it works. >>> >>> Here is the section: >>> >>> SQL requires a savepoint to be destroyed automatically when another >>> savepoint with the same name is established. In PostgreSQL, the old >>> savepoint is kept, though only the more recent one will be used when >>> rolling back or releasing. (Releasing the newer savepoint will cause the >>> older one to again become accessible to ROLLBACK TO SAVEPOINT and >>> RELEASE SAVEPOINT.) Otherwise, SAVEPOINT is fully SQL conforming. >> >> I'm confused. The sentence in brackets "Releasing the newer savepoint will cause the older one to again become accessibleto ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT" implies that you *will* walk backwards through all the savepointsnamed "a" if you repeatedly issue "ROLLBACK TO SAVEPOINT a", no? If that is not how it actually works, then thiswhole paragraph is wrong, I'd say. > > Releasing the newer savepoint will cause the older one to again become accessible, as the doc says, but rolling back toa savepoint does not implicitly release it. You'll have to use RELEASE SAVEPOINT for that. Ah, now I get it. Thanks. Would changing "Releasing the newer savepoint will cause ... " to "Explicitly releasing the newer savepoint" or maybe even"Explicitly releasing the newer savepoint with RELEASE SAVEPOINT will cause ..." make things clearer? best regards, Florian Pflug
Florian Pflug wrote: > On May 25, 2010, at 12:18 , Heikki Linnakangas wrote: > >> On 25/05/10 13:03, Florian Pflug wrote: >> >>> On May 25, 2010, at 6:08 , Sam Vilain wrote: >>> >>>> http://www.postgresql.org/docs/8.4/static/sql-savepoint.html >>>> >>>> Lead us to believe that if you roll back to the same savepoint name >>>> twice in a row, that you might start walking back through the >>>> savepoints. I guess I missed the note on ROLLBACK TO SAVEPOINT that >>>> that is not how it works. >>>> >>>> Here is the section: >>>> >>>> SQL requires a savepoint to be destroyed automatically when another >>>> savepoint with the same name is established. In PostgreSQL, the old >>>> savepoint is kept, though only the more recent one will be used when >>>> rolling back or releasing. (Releasing the newer savepoint will cause the >>>> older one to again become accessible to ROLLBACK TO SAVEPOINT and >>>> RELEASE SAVEPOINT.) Otherwise, SAVEPOINT is fully SQL conforming. >>>> >>> I'm confused. The sentence in brackets "Releasing the newer savepoint will cause the older one to again become accessibleto ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT" implies that you *will* walk backwards through all the savepointsnamed "a" if you repeatedly issue "ROLLBACK TO SAVEPOINT a", no? If that is not how it actually works, then thiswhole paragraph is wrong, I'd say. >>> >> Releasing the newer savepoint will cause the older one to again become accessible, as the doc says, but rolling back toa savepoint does not implicitly release it. You'll have to use RELEASE SAVEPOINT for that. >> > > Ah, now I get it. Thanks. > > Would changing "Releasing the newer savepoint will cause ... " to "Explicitly releasing the newer savepoint" or maybe even"Explicitly releasing the newer savepoint with RELEASE SAVEPOINT will cause ..." make things clearer? > Yes, probably - your misreading matches my misreading of it :-) There is another way you can get there - releasing to a savepoint before the re-used savepoint name will also release the savepoints after it. ie savepoint foo; savepoint bar; savepoint foo; release to savepoint bar; release to savepoint foo; After the first release, the second 'foo' savepoint is gone. I think this is a key advantage in saving the old savepoints. Cheers, Sam
On 26/05/10 02:00, Sam Vilain wrote: > Florian Pflug wrote: >> On May 25, 2010, at 12:18 , Heikki Linnakangas wrote: >>> Releasing the newer savepoint will cause the older one to again become accessible, as the doc says, but rolling backto a savepoint does not implicitly release it. You'll have to use RELEASE SAVEPOINT for that. >> >> Ah, now I get it. Thanks. >> >> Would changing "Releasing the newer savepoint will cause ... " to "Explicitly releasing the newer savepoint" or maybeeven "Explicitly releasing the newer savepoint with RELEASE SAVEPOINT will cause ..." make things clearer? > > Yes, probably - your misreading matches my misreading of it :-) +1. > There is another way you can get there - releasing to a savepoint before > the re-used savepoint name will also release the savepoints after it. > > ie > > savepoint foo; > savepoint bar; > savepoint foo; > release to savepoint bar; > release to savepoint foo; > > After the first release, the second 'foo' savepoint is gone. I think > this is a key advantage in saving the old savepoints. Yep. Do we need to mention that in that notice? I don't think so, it would become really verbose. Florian's wording above seems fine. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On May 27, 2010, at 0:58 , Heikki Linnakangas wrote: > On 26/05/10 02:00, Sam Vilain wrote: >> Florian Pflug wrote: >>> On May 25, 2010, at 12:18 , Heikki Linnakangas wrote: >>>> Releasing the newer savepoint will cause the older one to again become accessible, as the doc says, but rolling backto a savepoint does not implicitly release it. You'll have to use RELEASE SAVEPOINT for that. >>> >>> Ah, now I get it. Thanks. >>> >>> Would changing "Releasing the newer savepoint will cause ... " to "Explicitly releasing the newer savepoint" or maybeeven "Explicitly releasing the newer savepoint with RELEASE SAVEPOINT will cause ..." make things clearer? >> >> Yes, probably - your misreading matches my misreading of it :-) > > +1. Patch that changes the wording to "Explicitly releasing the newer savepoint with RELEASE SAVEPOINT will cause ..." is attached. Unfortunately, this patch is untested. I couldn't get openjade + DocBook to work on OSX for some reason :-( best regards, Florian Pflug
Attachment
On Wed, May 26, 2010 at 8:25 PM, Florian Pflug <fgp@phlo.org> wrote: > Unfortunately, this patch is untested. I couldn't get openjade + DocBook to work on OSX for some reason :-( That is a truly awful nightmare. Dave Page dug up some old instructions which got me through it - I'm guessing he doesn't mind my posting them, but let me double-check with him first. Actually, I think we should incorporate them into our docs. It's beyond me how anyone ever got this to work, even once. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On 27/05/10 12:25, Florian Pflug wrote: > > > Patch that changes the wording to "Explicitly releasing the newer savepoint with RELEASE SAVEPOINT will cause ..." is attached. > > Unfortunately, this patch is untested. I couldn't get openjade + DocBook to work on OSX for some reason :-( > > FWIW docs with this patch seem to build ok for me on Ubuntu Lucid 64 bit. regards Mark
On 27/05/10 03:25, Florian Pflug wrote: > On May 27, 2010, at 0:58 , Heikki Linnakangas wrote: >> On 26/05/10 02:00, Sam Vilain wrote: >>> Florian Pflug wrote: >>>> On May 25, 2010, at 12:18 , Heikki Linnakangas wrote: >>>>> Releasing the newer savepoint will cause the older one to again become accessible, as the doc says, but rolling backto a savepoint does not implicitly release it. You'll have to use RELEASE SAVEPOINT for that. >>>> >>>> Ah, now I get it. Thanks. >>>> >>>> Would changing "Releasing the newer savepoint will cause ... " to "Explicitly releasing the newer savepoint" or maybeeven "Explicitly releasing the newer savepoint with RELEASE SAVEPOINT will cause ..." make things clearer? >>> >>> Yes, probably - your misreading matches my misreading of it :-) >> >> +1. > > Patch that changes the wording to "Explicitly releasing the newer savepoint with RELEASE SAVEPOINT will cause ..." is attached. Thanks, committed. I left out the "Explicitly", though, because as Sam pointed out the newer savepoint can also be implicitly released by rolling back to an earlier savepoint. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com