Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@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