Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

<p dir="ltr"><br /> Dne 5.11.2015 19:02 napsal uživatel "Merlin Moncure" <<a
href="mailto:mmoncure@gmail.com">mmoncure@gmail.com</a>>:<br/> ><br /> > On Wed, Nov 4, 2015 at 4:15 PM,
StephenFrost <<a href="mailto:sfrost@snowman.net">sfrost@snowman.net</a>> wrote:<br /> > > * Joshua D.
Drake(<a href="mailto:jd@commandprompt.com">jd@commandprompt.com</a>) wrote:<br /> > >> On 11/04/2015 01:55
PM,Stephen Frost wrote:<br /> > >> >* Joe Conway (<a
href="mailto:mail@joeconway.com">mail@joeconway.com</a>)wrote:<br /> > >> >>On 11/04/2015 01:24 PM,
AlvaroHerrera wrote:<br /> > >> >>>I agree with Pavel.  Having a transaction timeout just does not
makeany<br /> > >> >>>sense.  I can see absolutely no use for it.  An idle-in-transaction<br /> >
>>>>>timeout, on the other hand, is very useful.<br /> > >> >><br /> > >>
>>+1-- agreed<br /> > >> ><br /> > >> >I'm not sure of that.  I can certainly see a use
fortransaction<br /> > >> >timeouts- after all, they hold locks and can be very disruptive in the<br />
>>> >long run.  Further, there are cases where a transaction is normally very<br /> > >> >fast
andin a corner case it becomes extremely slow and disruptive to<br /> > >> >the rest of the system.  In
thosecases, having a timeout for it is<br /> > >> >valuable.<br /> > >><br /> > >> Yeah
butanything holding a lock that long can be terminated via<br /> > >> statement_timeout can it not?<br /> >
><br/> > > Well, no?  statement_timeout is per-statement, while transaction_timeout<br /> > > is, well,
pertransaction.  If there's a process which is going and has<br /> > > an open transaction and it's holding
locks,that can be an issue.<br /> > ><br /> > > To be frank, my gut feeling is that transaction_timeout is
actuallymore<br /> > > useful than statement_timeout.<br /> ><br /> > Exactly.  statement_timeout is weak
becauseit resets for every<br /> > statement regardless of transaction.  Similarly, pg_cancel_backend is<br /> >
weakbecause it only works if a backend is actually in statement<br /> > regardless of transaction state (reading
thisthread, it's clear that<br /> > this is not widely known even among -hackers which further reinforces<br /> >
thepoint).<br /> ><br /> > Thus, I think we have consensus that transaction_timeout is good -- it<br /> >
woulddeprecate statement_timeout essentially.  Likewise,<br /> > pg_cancel_transaction is good and would deprecate
pg_cancel_backend;<br/> > it's hard for me to imagine a scenario where a user would call<br /> >
pg_cancel_backendif pg_cancel_transaction were to be available.<br /> ><p dir="ltr">I am sorry, I see a consensus
betweenyou and Stephen only.<p dir="ltr">Regards<p dir="ltr">Pavel<br /> > merlin<br />