On Wed, Mar 31, 2021 at 1:44 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > I read "exclusively locks" as meaning it takes an ExclusiveLock, but the code > shows that it takes an AccessExclusiveLock. I think the docs are pretty > misleading here, though I understand that grammatically it is hard to say > "accessively exclusively locks" or such. But a part of my analysis was based > on the reasoning that if VF only takes an ExclusiveLock, then there must be > concurrent readers possible. VF went away long enough ago that I had > forgotten exactly how inconvenient it was.
It kinda depends on what you mean by concurrent readers, because a transaction that could start on Monday and acquire an XID, and then on Tuesday you could run VACUUM FULL on relation "foo", and then on Wednesday the transaction from before could get around to reading some data from "foo". The two transactions are concurrent, in the sense that the 3-day transaction was running before the VACUUM FULL, was still running after VACUUM FULL, read the same pages that the VACUUM FULL modified, and cares whether the XID from the VACUUM FULL committed or aborted. But, it's not concurrent in the sense that you never have a situation where the VACUUM FULL does some of its modifications, then an overlapping transaction sees them, and then it does the rest of them. -- Robert Haas EDB: http://www.enterprisedb.com
