Re: "Idle in Transaction" revisited.

> On Sat, 18 Sep 2004, John R Pierce wrote:
>
>
>>> I can think of a bunch of scenarios where this would cause problems...
>>>
>>> *  An service app that opens several connections for various threads,
>>>    and one or another of them goes idle for a long time ... No vacuuming
>>>    during this state.
>
>
> This doesn't mean no vacuuming, only no vacuuming of old rows.  This can
> be difficult to actually detect so it's probably happening to people
> without them noticing.  They see a performance drop, but vacuum seems to
> work, so they don't see anything really wrong.
>
>
>>> *  Thread has been idle for awhile, then goes to do a SELECT and it will
>>>    only see data that was committed prior to this threads last COMMIT.
>>>
>
>
> This will only happen when working with serializable transaction
> isolation, not read committed (which is the default).
>

I'm still running against 7.3.x, but if the above two paragraphs
are true that's very problematic for me if I'm going to upgrade.
My app also runs 24/7 and uses serializable transactions in pooled
connections.

Are you saying that I will see stale database state at the logical
"start" of my transaction from a pooled connection?

That's a showstopper for sure. If I'm confused please enlighten me.
I've been holding off on upgrading because of the amount activity on
this list about 7.4+ systems.

This is the first thing that's been sufficiently integrity threatening
that it prompted me to de-lurk.  I need data as of when the transaction
starts, not when the database last committed a transaction via that
connection.