> 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.