Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 10:17:49AM -0700, Tom Lane wrote: > Josh Berkus writes: > > On 06/23/2014 03:52 PM, Andres Freund wrote: > >> True. Which makes me wonder whether we shouldn't default this to > >> something non-zero -- even if it is 5 or 10 days. > > > I'd go for even shorter: 48 hours.

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-29 19:51:05 -0400, Tom Lane wrote: > Andres Freund writes: > > Note that we're *inside* recv() here. > > Well, actually, the recv() has probably failed with an EINTR at this > point, or else it will when/if control returns. Well, the point is that we'll be reentering ssl when sending

Re: [HACKERS] idle_in_transaction_timeout

Andres Freund writes: > Note that we're *inside* recv() here. Well, actually, the recv() has probably failed with an EINTR at this point, or else it will when/if control returns. >> Uh, no, that would pretty much destroy the point of trying to report >> an error message at all. > I only mean th

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-29 19:13:55 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-29 12:53:56 -0400, Tom Lane wrote: > >> I do not think it is: specifically, the notion > >> that we will call ereport(FATAL) directly from a signal handler > >> does not fill me with warm fuzzies. > > > Aren't we

Re: [HACKERS] idle_in_transaction_timeout

Andres Freund writes: > On 2014-06-29 12:53:56 -0400, Tom Lane wrote: >> I do not think it is: specifically, the notion >> that we will call ereport(FATAL) directly from a signal handler >> does not fill me with warm fuzzies. > Aren't we already pretty much doing that for > SIGTERM/pg_terminate_b

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-29 17:28:06 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-29 15:48:15 -0400, Tom Lane wrote: > >> Robert Haas writes: > >>> Yeah, I think someone should do some analysis of whether this is > >>> adding gettimeofday() calls, and how many, and what the performance > >>> i

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-29 12:53:56 -0400, Tom Lane wrote: > I do not think it is: specifically, the notion > that we will call ereport(FATAL) directly from a signal handler > does not fill me with warm fuzzies. Aren't we already pretty much doing that for SIGTERM/pg_terminate_backend() and recovery conflict i

Re: [HACKERS] idle_in_transaction_timeout

Andres Freund writes: > On 2014-06-29 15:48:15 -0400, Tom Lane wrote: >> Robert Haas writes: >>> Yeah, I think someone should do some analysis of whether this is >>> adding gettimeofday() calls, and how many, and what the performance >>> implications are. >> I believe that as the patch stands, w

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-29 15:48:15 -0400, Tom Lane wrote: > Robert Haas writes: > > On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner wrote: > >> I propose to push this as it stands except for the postgres_fdw > >> part. The default is easy enough to change if we reach consensus, > >> and expanding the scope

Re: [HACKERS] idle_in_transaction_timeout

Robert Haas writes: > On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner wrote: >> I propose to push this as it stands except for the postgres_fdw >> part. The default is easy enough to change if we reach consensus, >> and expanding the scope can be a new patch in a new CF. >> Objections? > Yeah,

Re: [HACKERS] idle_in_transaction_timeout

On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner wrote: >>> Moreover, there would be no way to implement a timeout like that without >>> adding a gettimeofday() call after every packet receipt, which is overhead >>> we do not need and cannot afford. I don't think this feature should add >>> *

Re: [HACKERS] idle_in_transaction_timeout

Kevin Grittner writes: > I propose to push this as it stands except for the postgres_fdw > part.  The default is easy enough to change if we reach consensus, > and expanding the scope can be a new patch in a new CF. > Objections? There's been enough noise about the external definition that I thi

Re: [HACKERS] idle_in_transaction_timeout

Robert Haas wrote: > On Wed, Jun 25, 2014 at 11:40 AM, Tom Lane wrote: >> Fujii Masao writes: >>> Why is IIT timeout turned on only when send_ready_for_query is true? >>> I was thinking it should be turned on every time a message is received. >>> Imagine the case where the session is in idl

Re: [HACKERS] idle_in_transaction_timeout

On Wed, Jun 25, 2014 at 11:40 AM, Tom Lane wrote: > Fujii Masao writes: >> Why is IIT timeout turned on only when send_ready_for_query is true? >> I was thinking it should be turned on every time a message is received. >> Imagine the case where the session is in idle-in-transaction state and >> a

Re: [HACKERS] idle_in_transaction_timeout

On 06/26/2014 06:45 AM, Fujii Masao wrote: >> The point of this feature, AFAICS, is to detect clients that are failing >> > to issue another query or close their transaction as a result of bad >> > client logic. It's not to protect against network glitches. > > If so, the document should explain t

Re: [HACKERS] idle_in_transaction_timeout

On Thu, Jun 26, 2014 at 12:40 AM, Tom Lane wrote: > Fujii Masao writes: >> Why is IIT timeout turned on only when send_ready_for_query is true? >> I was thinking it should be turned on every time a message is received. >> Imagine the case where the session is in idle-in-transaction state and >> a

Re: [HACKERS] idle_in_transaction_timeout

Fujii Masao writes: > Why is IIT timeout turned on only when send_ready_for_query is true? > I was thinking it should be turned on every time a message is received. > Imagine the case where the session is in idle-in-transaction state and > a client gets stuck after sending Parse message and before

Re: [HACKERS] idle_in_transaction_timeout

On Sun, Jun 22, 2014 at 6:54 AM, Vik Fearing wrote: > On 06/21/2014 08:23 PM, Kevin Grittner wrote: >> OK, so I think we want to see a patch based on v1 (FATAL approach) >> with a change of the name to idle_in_transaction_session_timeout >> and the units changed to milliseconds. I don't see why t

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 10:17 AM, Tom Lane wrote: > Josh Berkus writes: >> On 06/23/2014 03:52 PM, Andres Freund wrote: >>> True. Which makes me wonder whether we shouldn't default this to >>> something non-zero -- even if it is 5 or 10 days. > >> I'd go for even shorter: 48 hours. I'd suggest 24 hours,

Re: [HACKERS] idle_in_transaction_timeout

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andres Freund writes: > > On 2014-06-24 10:17:49 -0700, Tom Lane wrote: > >> BTW, has anyone thought about the interaction of this feature with > >> prepared transactions? I wonder whether there shouldn't be a similar but > >> separately-settable maximum t

Re: [HACKERS] idle_in_transaction_timeout

Tom Lane wrote: > Josh Berkus writes: >>> Which makes me wonder whether we shouldn't default this to >>> something non-zero -- even if it is 5 or 10 days. > >> I'd go for even shorter: 48 hours.  I'd suggest 24 hours, but that >> would trip up some users who just need really long pg_dumps. > > F

Re: [HACKERS] idle_in_transaction_timeout

Andres Freund writes: > On 2014-06-24 10:17:49 -0700, Tom Lane wrote: >> BTW, has anyone thought about the interaction of this feature with >> prepared transactions? I wonder whether there shouldn't be a similar but >> separately-settable maximum time for a transaction to stay in the prepared >>

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-24 10:17:49 -0700, Tom Lane wrote: > BTW, has anyone thought about the interaction of this feature with > prepared transactions? I wonder whether there shouldn't be a similar but > separately-settable maximum time for a transaction to stay in the prepared > state. If we could set a non

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 07:17 PM, Tom Lane wrote: > BTW, has anyone thought about the interaction of this feature with > prepared transactions? I wonder whether there shouldn't be a similar but > separately-settable maximum time for a transaction to stay in the prepared > state. If we could set a nonzero d

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > On 06/23/2014 03:52 PM, Andres Freund wrote: >> True. Which makes me wonder whether we shouldn't default this to >> something non-zero -- even if it is 5 or 10 days. > I'd go for even shorter: 48 hours. I'd suggest 24 hours, but that would > trip up some users who just nee

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > On 06/24/2014 07:50 AM, Vik Fearing wrote: >> Once the remote times out, the local transaction is doomed (and won't >> even know it until it tries to commit). If we don't allow the fdw to be >> special, then the local transaction can't run at all. Ever. > I'm unclear on ho

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 07:50 AM, Vik Fearing wrote: > On 06/24/2014 04:04 PM, Robert Haas wrote: >>> If the local transaction is actually idle in transaction and the local server doesn't have a timeout, we're no worse off than before this patch. >> >> I think we are. First, the correct timeout is a ma

Re: [HACKERS] idle_in_transaction_timeout

2014-06-24 18:43 GMT+02:00 Josh Berkus : > On 06/23/2014 03:52 PM, Andres Freund wrote: > > On 2014-06-23 13:19:47 -0700, Kevin Grittner wrote: > > which already seems less clear (because the transaction belongs > > to idle) > >> > >> I have no idea what that means. > > > > It's "idle_in_t

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 06:43 PM, Josh Berkus wrote: A long idle in transaction state pretty much always indicates a >>> problematic interaction with postgres. >>> >> >>> >> True. Which makes me wonder whether we shouldn't default this to >>> >> something non-zero -- even if it is 5 or 10 days. >

Re: [HACKERS] idle_in_transaction_timeout

On 06/23/2014 03:52 PM, Andres Freund wrote: > On 2014-06-23 13:19:47 -0700, Kevin Grittner wrote: > which already seems less clear (because the transaction belongs > to idle) >> >> I have no idea what that means. > > It's "idle_in_transaction"_session_timeout. Not > "idle_in"_transaction_

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 11:11 AM, Robert Haas [via PostgreSQL] < ml-node+s1045698n5808915...@n5.nabble.com> wrote: > On Tue, Jun 24, 2014 at 10:50 AM, Vik Fearing <[hidden email] > > wrote: > > > On 06/24/2014 04:04 PM, Robert Haas wrote: > >>>

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 10:50 AM, Vik Fearing wrote: > On 06/24/2014 04:04 PM, Robert Haas wrote: >>> If the local transaction is actually idle in transaction and the local >>> > server doesn't have a timeout, we're no worse off than before this patch. >> >> I think we are. First, the correct tim

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 04:04 PM, Robert Haas wrote: >> If the local transaction is actually idle in transaction and the local >> > server doesn't have a timeout, we're no worse off than before this patch. > > I think we are. First, the correct timeout is a matter of > remote-server-policy, not local-server

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 10:05 AM, Robert Haas [via PostgreSQL] < ml-node+s1045698n580889...@n5.nabble.com> wrote: > On Tue, Jun 24, 2014 at 9:18 AM, Vik Fearing <[hidden email] > > wrote: > > > On 06/22/2014 05:11 PM, Kevin Grittner wrote: > >>

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-24 10:04:03 -0400, Robert Haas wrote: > On Tue, Jun 24, 2014 at 9:18 AM, Vik Fearing wrote: > > My reasoning for doing it the way I did is that if a transaction touches > > a foreign table and then goes bumbling along with other things the > > transaction is active but the connection to

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 9:18 AM, Vik Fearing wrote: > On 06/22/2014 05:11 PM, Kevin Grittner wrote: >> I found one substantive issue that had been missed in discussion, >> though. The patch modifies the postgres_fdw extension to make it >> automatically exempt from an attempt to set a limit like

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 03:29 PM, David G Johnston wrote: > On Tue, Jun 24, 2014 at 9:20 AM, Vik Fearing [via PostgreSQL] <[hidden > email] >wrote: > > On 06/22/2014 05:11 PM, Kevin Grittner wrote: > > I found one substantive issue that had been missed in discussion, > > though. The patch modif

Re: [HACKERS] idle_in_transaction_timeout

David G Johnston wrote: > Vik Fearing [via PostgreSQL] <[hidden email]>wrote: >> On 06/22/2014 05:11 PM, Kevin Grittner wrote: >>> I found one substantive issue that had been missed in discussion, >>> though.  The patch modifies the postgres_fdw extension to make it >>> automatically exempt from a

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 9:20 AM, Vik Fearing [via PostgreSQL] < ml-node+s1045698n5808882...@n5.nabble.com> wrote: > On 06/22/2014 05:11 PM, Kevin Grittner wrote: > > I found one substantive issue that had been missed in discussion, > > though. The patch modifies the postgres_fdw extension to make

Re: [HACKERS] idle_in_transaction_timeout

On 06/22/2014 05:11 PM, Kevin Grittner wrote: > I found one substantive issue that had been missed in discussion, > though. The patch modifies the postgres_fdw extension to make it > automatically exempt from an attempt to set a limit like this on > the server to which it connects. I'm not sure t

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-23 13:19:47 -0700, Kevin Grittner wrote: > >>> which already seems less clear (because the transaction belongs > >>> to idle) > > I have no idea what that means. It's "idle_in_transaction"_session_timeout. Not "idle_in"_transaction_session_timeout. > >>> and for another that distincti

Re: [HACKERS] idle_in_transaction_timeout

> > > A long idle in transaction state pretty much always indicates a > > problematic interaction with postgres. > > True. Which makes me wonder whether we shouldn't default this to > something non-zero -- even if it is 5 or 10 days. ​I guess it depends on how parental we want to be. But if we

Re: [HACKERS] idle_in_transaction_timeout

> > > >>> > >>> I think that'd be rather confusing. For one it'd need to be > >>> idle_in_transaction_timeout > > Why? We're cancelling an idle transaction, not an "idle in > transaction", whatever that is. > > ​The confusion derives from the fact we are affecting a session whose state is "idle in

Re: [HACKERS] idle_in_transaction_timeout

Andres Freund wrote: > On 2014-06-23 20:29:17 +0900, Fujii Masao wrote: >> On Mon, Jun 23, 2014 at 7:48 PM, Andres Freund >> wrote: >>> On 2014-06-22 19:03:32 -0700, Kevin Grittner wrote: Andres Freund wrote: > I think we'll want a version of this that just fails the > transac

Re: [HACKERS] idle_in_transaction_timeout

On 06/22/2014 09:02 PM, Abhijit Menon-Sen wrote: > I (somewhat reluctantly) agree with Kevin that > "idle_in_transaction_session_timeout" (for FATAL) and > "idle_transaction_timeout" (for ERROR) would work. Given that an IIT timeout has been a TODO for at least 6 years before being addressed, I'm

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-23 13:33:46 +0200, Vik Fearing wrote: > On 06/22/2014 07:47 PM, Andres Freund wrote: > > On 2014-06-22 09:27:24 -0700, Kevin Grittner wrote: > >> Andres Freund wrote: > > but I don't like that much. Not sure what'd be good, the best I > > currently can come up with is: > > idle_in_trans

Re: [HACKERS] idle_in_transaction_timeout

On 06/22/2014 07:47 PM, Andres Freund wrote: > On 2014-06-22 09:27:24 -0700, Kevin Grittner wrote: >> Andres Freund wrote: >> >>> The idea with the GUC name is that if we ever get support for >>> cancelling transactions we can name that >>> idle_in_transaction_transaction_timeout? >>> That seems a

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-23 20:29:17 +0900, Fujii Masao wrote: > On Mon, Jun 23, 2014 at 7:48 PM, Andres Freund wrote: > > On 2014-06-22 19:03:32 -0700, Kevin Grittner wrote: > >> Andres Freund wrote: > >> > >> > I think we'll want a version of this that just fails the > >> > transaction once we have the infra

Re: [HACKERS] idle_in_transaction_timeout

On Mon, Jun 23, 2014 at 7:48 PM, Andres Freund wrote: > On 2014-06-22 19:03:32 -0700, Kevin Grittner wrote: >> Andres Freund wrote: >> >> > I think we'll want a version of this that just fails the >> > transaction once we have the infrastructure. So we should choose >> > a name that allows for a

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-22 19:03:32 -0700, Kevin Grittner wrote: > Andres Freund wrote: > > > I think we'll want a version of this that just fails the > > transaction once we have the infrastructure. So we should choose > > a name that allows for a complimentary GUC. > > If we stick with the rule that what i

Re: [HACKERS] idle_in_transaction_timeout

At 2014-06-22 19:45:08 -0700, david.g.johns...@gmail.com wrote: > > On Sunday, June 22, 2014, Kevin Grittner-5 [via PostgreSQL] < > ml-node+s1045698n580830...@n5.nabble.com> wrote: > > > If we stick with the rule that what is to the left of _timeout is > > what is being cancelled, the a GUC to can

Re: [HACKERS] idle_in_transaction_timeout

On Sunday, June 22, 2014, Kevin Grittner-5 [via PostgreSQL] < ml-node+s1045698n580830...@n5.nabble.com> wrote: > Andres Freund <[hidden email] > > wrote: > > > I think we'll want a version of this that just fails the > > transaction once we hav

Re: [HACKERS] idle_in_transaction_timeout

Andres Freund wrote: > I think we'll want a version of this that just fails the > transaction once we have the infrastructure. So we should choose > a name that allows for a complimentary GUC. If we stick with the rule that what is to the left of _timeout is what is being cancelled, the a GUC to

Re: [HACKERS] idle_in_transaction_timeout

2014-06-22 19:47 GMT+02:00 Andres Freund : > On 2014-06-22 09:27:24 -0700, Kevin Grittner wrote: > > Andres Freund wrote: > > > > > The idea with the GUC name is that if we ever get support for > > > cancelling transactions we can name that > > > idle_in_transaction_transaction_timeout? > > > Tha

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-22 09:27:24 -0700, Kevin Grittner wrote: > Andres Freund wrote: > > > The idea with the GUC name is that if we ever get support for > > cancelling transactions we can name that > > idle_in_transaction_transaction_timeout? > > That seems a bit awkward... > > No, the argument was that f

Re: [HACKERS] idle_in_transaction_timeout

Andres Freund wrote: > The idea with the GUC name is that if we ever get support for > cancelling transactions we can name that > idle_in_transaction_transaction_timeout? > That seems a bit awkward... No, the argument was that for all the other *_timeout settings what came before _timeout was th

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-21 11:23:44 -0700, Kevin Grittner wrote: > Andrew Dunstan wrote: > > > > On 06/19/2014 06:33 PM, Josh Berkus wrote: > > >>> ISTM our realistic options are for seconds or msec as the unit.  If it's > >>> msec, we'd be limited to INT_MAX msec or around 600 hours at the top end, > >>> w

Re: [HACKERS] idle_in_transaction_timeout

Abhijit Menon-Sen > I've marked it Ready for Committer after a quick read-through. I took a pass through it with an eye toward committing it.  I found a couple minor whitespace issues, where the patch didn't follow conventional indenting practice; I can fix that no problem.  I found that as it s

Re: [HACKERS] idle_in_transaction_timeout

At 2014-06-21 23:54:58 +0200, vik.fear...@dalibo.com wrote: > > > I'll flip this to Waiting on Author for those changes. > > And back to Needs Review. I've marked it Ready for Committer after a quick read-through. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or

Re: [HACKERS] idle_in_transaction_timeout

On 06/21/2014 08:23 PM, Kevin Grittner wrote: > OK, so I think we want to see a patch based on v1 (FATAL approach) > with a change of the name to idle_in_transaction_session_timeout > and the units changed to milliseconds. I don't see why the > remoteversion test shouldn't be changed to use 90500

Re: [HACKERS] idle_in_transaction_timeout

Andrew Dunstan wrote: > On 06/19/2014 06:33 PM, Josh Berkus wrote: >>> ISTM our realistic options are for seconds or msec as the unit.  If it's >>> msec, we'd be limited to INT_MAX msec or around 600 hours at the top end, >>> which seems like enough to me but maybe somebody thinks differently?

Re: [HACKERS] idle_in_transaction_timeout

On 06/19/2014 06:33 PM, Josh Berkus wrote: Tom, ISTM our realistic options are for seconds or msec as the unit. If it's msec, we'd be limited to INT_MAX msec or around 600 hours at the top end, which seems like enough to me but maybe somebody thinks differently? Seconds are probably OK but I'

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus wrote: > Tom, > > > ISTM our realistic options are for seconds or msec as the unit. If it's > > msec, we'd be limited to INT_MAX msec or around 600 hours at the top end, > > which seems like enough to me but maybe somebody thinks differently? > > Seconds are probably OK but I'm worrie

Re: [HACKERS] idle_in_transaction_timeout

Tom, > ISTM our realistic options are for seconds or msec as the unit. If it's > msec, we'd be limited to INT_MAX msec or around 600 hours at the top end, > which seems like enough to me but maybe somebody thinks differently? > Seconds are probably OK but I'm worried about somebody complaining th

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > Now ... can we decrease CPU overhead (wakeups) if we only check once per > minute? If so, there's a good argument for making 1min the minimum. Polling wakeups are right out, and are unnecessary anyway. The utils/misc/timeout.c infrastructure calculates the time left till

Re: [HACKERS] idle_in_transaction_timeout

On 06/19/2014 02:44 PM, Kevin Grittner wrote: > Josh Berkus wrote: > >> Also, I really hope that nobody is setting this to 10s ... > > Well, we get to decide what the minimum allowed value is. What do > you think that should be? 1s? I don't think that setting it to 1s would ever be a good ide

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus wrote: > Also, I really hope that nobody is setting this to 10s ... Well, we get to decide what the minimum allowed value is.  What do you think that should be? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing

Re: [HACKERS] idle_in_transaction_timeout

On 06/19/2014 10:39 AM, David G Johnston wrote: > Advocating for the Devil (or a more robust, if probably complicated, > solution): > "idle_in_transaction_timeout=10s" > "idle_in_transaction_target=session|transaction" Per Kevin Grittner's assessment, aborting the transaction is currently a nonsta

Re: [HACKERS] idle_in_transaction_timeout

On Thu, Jun 19, 2014 at 12:40 PM, Abhijit Menon-Sen-2 [via PostgreSQL] < ml-node+s1045698n5808016...@n5.nabble.com> wrote: > At 2014-06-19 17:53:17 +0200, [hidden email] > wrote: > > > > I much prefer with "in" but it doesn't much matter. > >

Re: [HACKERS] idle_in_transaction_timeout

At 2014-06-19 17:53:17 +0200, vik.fear...@dalibo.com wrote: > > I much prefer with "in" but it doesn't much matter. If you look at similar settings like statement_timeout, lock_timeout, etc., what comes before the _timeout is a concrete *thing* that can timeout, or that a timeout can be applied to

Re: [HACKERS] idle_in_transaction_timeout

At 2014-06-19 08:42:01 -0700, kgri...@ymail.com wrote: > > I'm not sure whether using the same name as pgbouncer for the same > functionality makes it less confusing or might lead to confusion > about which layer is disconnecting the client. I don't think the names of the respective configuration

Re: [HACKERS] idle_in_transaction_timeout

On 06/19/2014 05:42 PM, Kevin Grittner wrote: > Abhijit Menon-Sen wrote: >> At 2014-06-19 10:58:34 +0200, pavel.steh...@gmail.com wrote: > >>> pgbouncer has idle_transaction_timeout defined some years >>> without any problems, so we can take this design >>> >>> idle_transaction_timeout >> >> Let'

Re: [HACKERS] idle_in_transaction_timeout

Abhijit Menon-Sen wrote: > At 2014-06-19 10:58:34 +0200, pavel.steh...@gmail.com wrote: >> pgbouncer has idle_transaction_timeout defined some years >> without any problems, so we can take this design >> >> idle_transaction_timeout > > Let's steal the name too. :-) > > (I didn't realise there was

Re: [HACKERS] idle_in_transaction_timeout

At 2014-06-19 10:58:34 +0200, pavel.steh...@gmail.com wrote: > > Hello > > pgbouncer has idle_transaction_timeout defined some years without any > problems, so we can take this design > > idle_transaction_timeout Let's steal the name too. :-) (I didn't realise there was precedent in pgbouncer,

Re: [HACKERS] idle_in_transaction_timeout

Hello pgbouncer has idle_transaction_timeout defined some years without any problems, so we can take this design idle_transaction_timeout If client has been in "idle in transaction" state longer, it will be disconnected. [seconds] Default: 0.0 (disabled) This feature can be very important, and

Re: [HACKERS] idle_in_transaction_timeout

On Wed, Jun 18, 2014 at 8:01 PM, Josh Berkus [via PostgreSQL] < ml-node+s1045698n5807868...@n5.nabble.com> wrote: > On 06/18/2014 04:54 PM, Marko Tiikkaja wrote: > > On 2014-06-19 1:46 AM, Josh Berkus wrote: > >> Robert's right, not killing the "BEGIN;" only transactions is liable to > >> result i

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > Counter-argument: most app frameworks which do an automatic BEGIN; also > do other stuff like SET TIMEZONE each time as well. Is this really a > case worth worrying about? SET TIMEZONE doesn't result in taking a snapshot either. regards, tom lane

Re: [HACKERS] idle_in_transaction_timeout

On 06/18/2014 04:54 PM, Marko Tiikkaja wrote: > On 2014-06-19 1:46 AM, Josh Berkus wrote: >> Robert's right, not killing the "BEGIN;" only transactions is liable to >> result in user confusion unless we label those sessions differently in >> pg_stat_activity. > > Wouldn't they be labeled different

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-19 1:46 AM, Josh Berkus wrote: Robert's right, not killing the "BEGIN;" only transactions is liable to result in user confusion unless we label those sessions differently in pg_stat_activity. Wouldn't they be labeled differently already? i.e. the last query would be "BEGIN". Unles

Re: [HACKERS] idle_in_transaction_timeout

On 06/18/2014 02:52 PM, Bruce Momjian wrote: > On Wed, Jun 18, 2014 at 04:41:30PM -0400, Robert Haas wrote: >> The only problem I see is that it makes the semantics kind of weird >> and confusing. "Kill connections that are idle in transaction for too >> long" is a pretty clear spec; "kill connect

Re: [HACKERS] idle_in_transaction_timeout

On Wed, Jun 18, 2014 at 04:41:30PM -0400, Robert Haas wrote: > On Wed, Jun 18, 2014 at 3:53 PM, Josh Berkus wrote: > > On 06/18/2014 12:32 PM, Tom Lane wrote: > >> Josh Berkus writes: > >>> There are plenty of badly-written applications which "auto-begin", that > >>> is, they issue a "BEGIN;" im

Re: [HACKERS] idle_in_transaction_timeout

On Wed, Jun 18, 2014 at 3:53 PM, Josh Berkus wrote: > On 06/18/2014 12:32 PM, Tom Lane wrote: >> Josh Berkus writes: >>> There are plenty of badly-written applications which "auto-begin", that >>> is, they issue a "BEGIN;" immediately after every "COMMIT;" whether or >>> not there's any addition

Re: [HACKERS] idle_in_transaction_timeout

On 06/18/2014 12:32 PM, Tom Lane wrote: > Josh Berkus writes: >> There are plenty of badly-written applications which "auto-begin", that >> is, they issue a "BEGIN;" immediately after every "COMMIT;" whether or >> not there's any additional work to do. This is a major source of IIT >> and the ti

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > There are plenty of badly-written applications which "auto-begin", that > is, they issue a "BEGIN;" immediately after every "COMMIT;" whether or > not there's any additional work to do. This is a major source of IIT > and the timeout should not ignore it. Nonsense. We exp

Re: [HACKERS] idle_in_transaction_timeout

On 06/18/2014 11:50 AM, Kevin Grittner wrote: > The first thing is that I don't think a delay between the BEGIN and > the SELECT should cause a timeout to trigger, but more importantly > there should not be two ERROR responses to one SELECT statement. I do think a delay between BEGIN and SELECT sh

Re: [HACKERS] idle_in_transaction_timeout

Robert Haas wrote: > Tom Lane wrote: >> Robert Haas writes: >>> I thought the reason why this hasn't been implemented before >>> now is that sending an ErrorResponse to the client will result >>> in a loss of protocol sync. >> >> Hmm ... you are right that this isn't as simple as an >> ereport(

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 3, 2014 at 11:37 PM, Tom Lane wrote: > Robert Haas writes: >> I thought the reason why this hasn't been implemented before now is >> that sending an ErrorResponse to the client will result in a loss of >> protocol sync. > > Hmm ... you are right that this isn't as simple as an ereport

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-03 23:37:28 -0400, Tom Lane wrote: > Robert Haas writes: > > I thought the reason why this hasn't been implemented before now is > > that sending an ErrorResponse to the client will result in a loss of > > protocol sync. > > Hmm ... you are right that this isn't as simple as an ereport

Re: [HACKERS] idle_in_transaction_timeout

Robert Haas writes: > I thought the reason why this hasn't been implemented before now is > that sending an ErrorResponse to the client will result in a loss of > protocol sync. Hmm ... you are right that this isn't as simple as an ereport(ERROR), but I'm not sure it's impossible. We could for i

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 3, 2014 at 5:53 PM, Tom Lane wrote: > Josh Berkus writes: >> Out of curiosity, how much harder would it have been just to abort the >> transaction? I think breaking the connection is probably the right >> behavior, but before folks start arguing it out, I wanted to know if >> abortin

Re: [HACKERS] idle_in_transaction_timeout

On 06/04/2014 02:01 AM, David G Johnston wrote: > ​Default to dropping the connection but give the usersadministrators > the capability to decide for themselves? Meh. > I still haven't heard an argument for why this wouldn't apply to > aborted idle-in-transactions. I get the focus in on releasin

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 3, 2014 at 7:40 PM, Josh Berkus [via PostgreSQL] < ml-node+s1045698n5805933...@n5.nabble.com> wrote: > On 06/03/2014 02:53 PM, Tom Lane wrote: > > > Josh Berkus <[hidden email] > > writes: > >> Out of curiosity, how much harder woul

Re: [HACKERS] idle_in_transaction_timeout

On 06/04/2014 01:38 AM, Josh Berkus wrote: > On 06/03/2014 02:53 PM, Tom Lane wrote: >> Josh Berkus writes: >>> Out of curiosity, how much harder would it have been just to abort the >>> transaction? I think breaking the connection is probably the right >>> behavior, but before folks start arguin

Re: [HACKERS] idle_in_transaction_timeout

On 06/03/2014 02:53 PM, Tom Lane wrote: > Josh Berkus writes: >> Out of curiosity, how much harder would it have been just to abort the >> transaction? I think breaking the connection is probably the right >> behavior, but before folks start arguing it out, I wanted to know if >> aborting the tra

Re: [HACKERS] idle_in_transaction_timeout

On 06/03/2014 05:53 PM, Tom Lane wrote: Josh Berkus writes: Out of curiosity, how much harder would it have been just to abort the transaction? I think breaking the connection is probably the right behavior, but before folks start arguing it out, I wanted to know if aborting the transaction i

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus wrote: > Argument in favor of breaking the connection: most of the time, IITs are > caused by poor error-handling or garbage-collection code on the client > side, which has already abandoned the application session but hadn't let > go of the database handle. Since the application is n

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > Out of curiosity, how much harder would it have been just to abort the > transaction? I think breaking the connection is probably the right > behavior, but before folks start arguing it out, I wanted to know if > aborting the transaction is even a reasonable thing to do. FW

Re: [HACKERS] idle_in_transaction_timeout

Vik, > When the timeout occurs, the backend commits suicide with a FATAL > ereport. I thought about just aborting the transaction to free the > locks but decided that the client is clearly broken so might as well > free up the connection as well. Out of curiosity, how much harder would it have b

Re: [HACKERS] idle_in_transaction_timeout

Vik Fearing wrote > On 06/03/2014 03:30 PM, Abhijit Menon-Sen wrote: >> At 2014-06-03 15:06:11 +0200, > vik.fearing@ > wrote: >>> This patch implements a timeout for broken clients that idle in >>> transaction. >> I think this is a nice feature, but I suggest that (at the very least) >> the GUC

Re: [HACKERS] idle_in_transaction_timeout

On 06/03/2014 03:30 PM, Abhijit Menon-Sen wrote: > At 2014-06-03 15:06:11 +0200, vik.fear...@dalibo.com wrote: >> This patch implements a timeout for broken clients that idle in >> transaction. > I think this is a nice feature, but I suggest that (at the very least) > the GUC should be named "idle_

  1   2   >