<div dir="ltr"><div class="gmail_quote">On Tue, Sep 27, 2011 at 7:57 PM, Will Leinweber <span dir="ltr"><<a
href="mailto:will@heroku.com">will@heroku.com</a>></span>wrote:<br /><blockquote class="gmail_quote" style="margin:
0pt0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I ruined a 5 hour UPDATE by typoing a
tablename on a SELECT to verify<br /> the update worked. I suppose I have no one else to blame, but it was<br /> really
frustrating,to say the least. I assume this has happened to<br /> others as well.<br /><br /> I only later found out
aboutSAVEPOINT, which I immediately ran the<br /> next time I attempted the huge update.<br /><br /> psql console,
whilein a transaction, and while in interactive mode,<br /> should savepoint for me.<br /><br clear="all"
/></blockquote></div><br/>I guess it would be a neat feature to have this in Postgres rather than in psql. That is, if
runningin an explicit transaction (one started with BEGIN), issue a savepoint after/before every command and emit the
savepointname in a NOTICE.<br /><br /> I *think* savepoints are detrimental to performance, maybe under certain
pre-conditions,so it might be desirable to control it using a user-settable parameter.<br /><br /> If there's no
perceivableperformance difference in using savepoints even under large transactions, then we might want to make it all
automaticand transparent. So Postgres issues a savepoint before every command, and if the command fails, rollback to
thatsavepoint, else release that savepoint.<br /><br /> Regards,<br />-- <br /><div dir="ltr">Gurjeet Singh<br
/>EnterpriseDBCorporation<br />The Enterprise PostgreSQL Company<br /></div><br /></div>
