Re: Lazy Snapshots

simon@2ndquadrant.com wrote:
> * Scan begins, no snapshot set. Ahead of scan a row that would have been visible
> at start of scan is deleted, commits and removed by VACUUM/HOT. The scan has no
> evidence that a removal has taken place, never sees contention and thus never
> takes a snapshot. This isn't a problem; the row removal created an implicit xmin
> for our scan. If we later took a snapshot the xmin of the snapshot would be
> equal or later than our previous implicit xmin and so MVCC would be working.
> This shows that it is wrong to presume that taking no snapshot at all means that
> the time consistent point on the scan was at the start of a statement, it may
> not be.

I don't understand this part. Imagine this:

Transaction A: start query "SELECT * FROM foo;"
Transaction B: BEGIN; DELETE FROM foo WHERE id = 1 OR id = 100000; COMMIT
Transaction A: query finishes.

How do you ensure that the query sees either both or neither of the
deleted tuples?

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com