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. I thought there were many call sites that were specifically depending on seeing dirty reads to avoid race conditions with other backends -- which probably just narrowed the race condition or created different ones. If you clean those all up it will be probably be cleaner and better but we don't know how many such sites will need to be modified. I'm not even sure what "clean them up" means. You can replace checks with things like constraints and locks but the implementation of constraints and locks will still need to use SnapshotNow surely? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
