Stephen Frost <sfr...@snowman.net> writes:
> It turns out that createdb() currently only takes an AccessShareLock
> on pg_tablespace when scanning it with SnapshotNow, making it possible
> for a concurrent process to make some uninteresting modification to a
> tablespace (such as an ACL change) which will cause the heap scan in
> createdb() to see a given tablespace multiple times. copydir() will
> then, rightfully, complain that it's being asked to create a directory
> which already exists.
Ugh. Still another problem with non-MVCC catalog scans.
> Given that this is during createdb(), I'm guessing we don't have any
> option but to switch the scan to using ShareLock, since there isn't a
> snapshot available to do an MVCC scan with (I'm guessing that there
> could be other issues trying to do that anyway).
It seems that the only thing we actually use from each tuple is the OID.
So there are other ways to fix it, of which probably the minimum-change
one is to keep a list of already-processed tablespace OIDs and skip a
tuple if we get a match in the list. This would be O(N^2) in the number
of tablespaces, but I rather doubt that's a problem.
[ 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 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.
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
