Robert Haas <robertmh...@gmail.com> writes: > Department of second thoughts: I think I see a problem.
Um, yeah, so that doesn't really work any better than my idea. On further reflection, there's a problem at a higher level than this anyway. Even if we can get a single SnapshotNow scan to produce guaranteed-self-consistent results, that doesn't ensure consistency between the results of scans occurring serially. An example here is ALTER COLUMN DROP DEFAULT, which is currently imagined to impact only writers. However, suppose that a concurrent relcache load fetches the pg_attribute row, notes that it has atthasdef = true, and then the ALTER commits before we start to scan pg_attrdef. The consistency checks in AttrDefaultFetch() will complain about a missing pg_attrdef entry, and rightly so. We could lobotomize those checks, but it doesn't feel right to do so; and anyway there may be other cases that are harder to kluge up. So really we need consistency across *at least* one entire relcache load cycle. We could maybe arrange to take an MVCC snap (or some lighter weight version of that) at the start, and use that for all the resulting scans, but I think that would be notationally messy. It's not clear that it'd solve everything anyhow. There are parts of a relcache entry that we fetch only on-demand, so they are typically loaded later than the core items, and probably couldn't use the same snapshot. Worse, there are lots of places where we assume that use of catcache entries or direct examination of the catalogs will yield results consistent with the relcache. I suspect these latter problems will impact Simon's idea as well. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers