On Wed, Mar 31, 2021 at 1:44 PM Mark Dilger
<mark.dilger@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
anExclusiveLock, then there must be concurrent readers possible. VF went away long enough ago that I had forgotten
exactlyhow 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
