Teodor Sigaev <teodor@sigaev.ru> writes:
>> I started to look at this. I don't understand why VACUUM does an insert
>> cleanup before starting to vacuum, but VACUUM FULL doesn't?
> Hmm. May be I missed something, but I don't understand where and what... I tried
> to track all places of ambultdelete call. aminsertcleanup should be called
> before any ambulkdelete, because ambulkdelete doesn't scan pending list which
> can store items to be deleted and hence index will store item pointers to absent
> tuples.
>> needed is the one at vacuum startup, which tempts me to propose that
>> the new AM entry point should be called "amvacuumstartup", instead of
>> wiring in the assumption that what it's for is specifically cleanup
>> of insertions.
> That's possible but inserts into index should be forbidden between
> amvacuumstartup and last call of ambulkdelete.
Well, if that is required to be true then this whole design is pretty
broken, because VACUUM doesn't hold any lock that would guarantee that
no insert happens between the two calls. If we fold the two AM calls
into one call then it'd be okay for the index AM to take such a lock
transiently during the single index-cleanup-plus-bulkdelete call.
For VACUUM FULL there's no such issue because the whole table is locked,
but I still don't see any real point in having two successive index AM
calls when the AM could perfectly well do all the work in one call.
Maybe it'd be better if ambulkdelete *did* scan the pending list?
You'd still need at least page-level locking but perhaps not anything
stronger.
regards, tom lane
