Re: <IDLE> in transaction

On Fri, Aug 19, 2005 at 07:06:02PM -0400, Alvaro Herrera wrote:
> On Fri, Aug 19, 2005 at 11:55:19AM -0700, elein wrote:
> > I'm cross posting to INTERFACES. Please follow up
> > on INTERFACES and not on general. Cross posting is evil.
>
> Well, I'm not on -interfaces, so I'll reply to both :-) I don't worry
> too much about crossposting, because a) it's commonplace in PostgreSQL
> lists, and b) majordomo can deliver a single copy of the message if you
> configure it to do so.
>
>
> > > Some of these I-i-t connections come and go after a while.
> > > Some stick around for DAYS.
> > >
> > > If ANYONE has any brilliant ideas as to the source and
> > > dare I say correction to this problem, many people, especially
> > > myself would be very very happy.
>
> While this is a purely client-side problem, which is the client issuing
> a BEGIN right after a COMMIT, we talked about coding around it
> server-side, back in the time when I was doing nested transactions.
> It didn't get done though. I think if you push hard enough, somebody
> (myself?) may do it for 8.2.

To replicate the situation is psql:
BEGIN;
select something;

In another window I see that I have not only shared access locks
but an exclusive access lock. I do not understand why the exclusive
lock is there. Am I seeing ghosts?

Also, for some relief we found a piece of code that forgot its
commit. That helped a lot but I'm not convinced it was the only place
this occurred.

--elein

>
> Of course, this is no solution if the client started a transaction, did
> some work, and then sat on the connection with the transaction open for
> days. But this is not a common case and is certainly much more broken,
> if only because other RDBMS behave more reasonably in the COMMIT-BEGIN
> scenario.
>
> --
> Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
> "La persona que no quería pecar / estaba obligada a sentarse
> en duras y empinadas sillas / desprovistas, por cierto
> de blandos atenuantes" (Patricio Vogel)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>