Tom Lane <[EMAIL PROTECTED]> writes:
> We have to start the transaction no later than event #2 since there has
> to be something to hold the lock. But it'd be easy enough to decouple
> this from BEGIN, and it'd be good enough to solve the "COMMIT;BEGIN"
> problem.
Oh I think I finally figured out what you're saying here.
So vacuum doesn't really know what tuples are actually visible to the
snapshots actually taken by a transaction? It's making the conservative
estimate that a snapshot could have been taken as early as the start of the
transaction even if no snapshot was taken until later?
> Which of these three times do you think now() ought to correspond to?
> I recall having argued that it should be event #3 since that corresponds
> to the database snapshot you see. 100% backwards compatibility would
> require setting now() at event #1, but will anyone weep if we change that?
I think it would be weird to perform a select and see records with dates after
now(). It would also be weird to perform a select and not see records inserted
before now(). I'm not sure any of the above guarantees those criteria for READ
COMMITTED mode, but I think I'm on the same general path as you.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
