<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Mon, Mar 16, 2015 at 11:46 AM, Robert
Haas<span dir="ltr"><<a href="mailto:robertmhaas@gmail.com" target="_blank">robertmhaas@gmail.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">OnSun, Mar 15, 2015 at 8:04 PM, Rui DeSousa <<a href="mailto:rui@crazybean.net">rui@crazybean.net</a>>
wrote:<br/> > Would a parameter to auto terminate long running transactions be a better solution? Terminating the
longrunning transaction would allow for the normal vacuuming process to cleanup the deleted records thus avoiding
databasebloat without introducing new semantics to Postgres's MVCC. I would also recommend that the default be
disabled.<br/><br /></span>An advantage of Kevin's approach is that you don't have to abort *all*<br /> long-running
transactions,only those that touch data which has been<br /> modified since then. If your system is read-mostly, that
could<br/> dramatically reduce the number of aborts.<br /><span class="HOEnZb"><font color="#888888"></font></span><br
/></blockquote></div><br/></div><div class="gmail_extra">Indeed. The suggestion of auto-terminating long running
transactionsmisses the point, ISTM. Most of the use cases I can see for this involve vacuuming tables that the long
runningtransaction will have no interest in at all (which is why I suggested being able to set it on a per table
basis).I certainly don't want to be terminating my long running report transaction so that my queue table which is only
evertouched by very short-lived transactions can be reasonably vacuumed. But that's what we have to do now.<br /><br
/></div><divclass="gmail_extra">cheers<br /><br /></div><div class="gmail_extra">andrew<br /></div></div>