si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
