Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> [ thinks for a bit... ] Ugh, no, because the *other* risk you've got >> here is not seeing a row at all, which would be really bad.
> I'm not sure that I see how that could happen..? I agree that it'd be > really bad if it did though. Or are you thinking if we were to take a > snapshot and then walk the table? The case where you see a tuple twice is if an update drops a new version of a row beyond your seqscan, and then commits before you get to the new version. But if it drops the new version of the row *behind* your seqscan, and then commits before you get to the original tuple, you'll not see either row version as committed. Both of these cases are inherent risks in SnapshotNow scans. >> I'm not sure that transiently increasing the lock here is enough, >> either. The concurrent transactions you're worried about probably >> aren't holding their locks till commit, so you could get this lock >> and still see tuples with unstable committed-good states. > If there are other transactiosn which have open locks against the table, > wouldn't that prevent my being able to acquire ShareLock on it? What I'm worried about is that we very commonly release locks on catalogs as soon as we're done with the immediate operation --- not only read locks, but update locks as well. So there are lots of cases where locks are released before commit. It's possible that that never happens in operations applied to pg_tablespace, but I'd not want to bet on it. I wonder whether it's practical to look at the on-disk directories instead of relying on pg_tablespace for this particular purpose. Or maybe we should just write this off as a case we can't realistically fix before we have MVCC catalog scans. It seems that any other fix is going to be hopelessly ugly. 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