Re: Idle In Transaction Session Timeout, revived

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Vik Fearing <vik(at)2ndquadrant(dot)fr>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Idle In Transaction Session Timeout, revived
Date: 2016-02-03 21:25:03
Message-ID: 24366.1454534703@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Feb 3, 2016 at 3:41 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
>> Wouldn't it be more sensible to just roll the transaction back and not
>> disconnect?

> It would be nice to be able to do that, but the client-server protocol
> can't handle it without losing sync. Basically, if you send an error
> to an idle client, you have to kill the session. This has come up
> many times before.

Well, you can't just spit out an unprompted error message and go back to
waiting for the next command; as Robert says, that would leave the wire
protocol state out of sync. But in principle we could kill the
transaction and not say anything to the client right then. Instead set
some state that causes the next command from the client to get an error.
(This would not be much different from what happens when you send a
command in an already-reported-failed transaction; though we'd want to
issue a different error message than for that case.)

I'm not sure how messy this would be in practice. But if we think that
killing the whole session is not desirable but something we're doing for
expediency, then it would be worth looking into that approach.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2016-02-03 22:05:44 Re: Idle In Transaction Session Timeout, revived
Previous Message Tom Lane 2016-02-03 21:16:17 Re: PostgreSQL Audit Extension