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 accessible to ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT" implies that you *will* walk backwards through all the savepoints named "a" if you repeatedly issue "ROLLBACK TO SAVEPOINT a", no? If that is not how it actually works, then this whole 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 accessible to ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT" implies that you *will* walk backwards through all the savepoints named "a" if you repeatedly issue "ROLLBACK TO SAVEPOINT a", no? If that is not how it actually works, then this whole 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 accessible to ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT" implies that you *will* walk backwards through all the savepoints named "a" if you repeatedly issue "ROLLBACK TO SAVEPOINT a", no? If that is not how it actually works, then this whole 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.
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 accessible to ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT" implies that you *will* walk backwards through all the savepoints named "a" if you repeatedly issue "ROLLBACK TO SAVEPOINT a", no? If that is not how it actually works, then this whole 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.
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 back to 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 maybe even "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 back to 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 maybe even "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
Attachments:
doc-savepoint-explicitrelease.patchapplication/octet-stream; name=doc-savepoint-explicitrelease.patchDownload
diff --git a/doc/src/sgml/ref/savepoint.sgml b/doc/src/sgml/ref/savepoint.sgml
index c327b6b..90d3895 100644
*** a/doc/src/sgml/ref/savepoint.sgml
--- b/doc/src/sgml/ref/savepoint.sgml
*************** COMMIT;
*** 115,124 ****
SQL requires a savepoint to be destroyed automatically when another
savepoint with the same name is established. In
<productname>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
! <command>ROLLBACK TO SAVEPOINT</> and <command>RELEASE SAVEPOINT</>.)
! Otherwise, <command>SAVEPOINT</command> is fully SQL conforming.
</para>
</refsect1>
--- 115,125 ----
SQL requires a savepoint to be destroyed automatically when another
savepoint with the same name is established. In
<productname>PostgreSQL</>, the old savepoint is kept, though only the more
! recent one will be used when rolling back or releasing. (Explicitly
! releasing the newer savepoint with <command>RELEASE SAVEPOINT</> will cause
! the older one to again become accessible to <command>ROLLBACK TO SAVEPOINT</>
! and <command>RELEASE SAVEPOINT</>.) Otherwise, <command>SAVEPOINT</command> is
! fully SQL conforming.
</para>
</refsect1>
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 back to 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 maybe even "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