On Wed, Jun 5, 2013 at 10:28 AM, Greg Stark <st...@mit.edu> wrote: > On Wed, May 22, 2013 at 3:18 AM, Robert Haas <robertmh...@gmail.com> wrote: >> We've had a number of discussions about the evils of SnapshotNow. As >> far as I can tell, nobody likes it and everybody wants it gone, but >> there is concern about the performance impact. > > I was always under the impression that the problem was we weren't > quite sure what changes would be needed to make mvcc-snapshots work > for the catalog lookups. The semantics of SnapshotNow aren't terribly > clear either but we have years of experience telling us they seem to > basically work. Most of the problems we've run into we either have > worked around in the catalog accesses. Nobody really knows how many of > the call sites will need different logic to behave properly with mvcc > snapshots.
With all respect, I think this is just plain wrong. SnapshotNow is just like an up-to-date MVCC snapshot. The only difference is that an MVCC snapshot, once established, stays fixed for the lifetime of the scan. On the other hand, the SnapshotNow view in the world changes the instant another transaction commits, meaning that scans can see multiple versions of a row, or no versions of a row, where any MVCC scan would have seen just one. There are very few places that want that behavior. Now, I did find a couple that I thought should probably stick with SnapshotNow, specifically pgrowlocks and pgstattuple. Those are just gathering statistical information, so there's no harm in having the snapshot change part-way through the scan, and if the scan is long, the user might actually regard the results under SnapshotNow as more accurate. Whether that's the case or not, holding back xmin for those kinds of scans does not seem wise. But in most other parts of the code, the changes-in-mid-scan behavior of SnapshotNow is a huge liability. The fact that it is fully up-to-date *as of the time the scan starts* is critical for correctness. But the fact that it can then change during the scan is in almost every case something that we do not want. The patch preserves the first property while ditching the second one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
