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.
Actually, lock doesn't needed. Just bulkdelete should not try to remove not yet
"insertcleanuped" items pointer. That's easy because VacPageList is prepared
before insertcleanup call.
Maybe it'd be better if ambulkdelete *did* scan the pending list?
I don't like that idea because it requires to add a lot of code (concurrent
deletion of pages in list), much simpler to call insertcleanup inside
ginbulkdelete/ginvacuumcleanup.
You'd still need at least page-level locking but perhaps not anything
stronger.
That's close to trivial to revert this piece to add cleanup call to
ginbulkdelete/ginvacuumcleanup. Early variants used this variant.
Reasons for new variant was:
- defining needing of call of insertcleanup, and stats argument was used for
it in both function. If it's a NULL then call cleanup.
- I thought about statistic-based trigger for separate call of insertcleanup.
Trigger should be fired on massive insert/update events very similar to
trigger on massive delete for ambulkdelete. I'm very sorry but I didn't do it
yet, and definitely I need some help here.
Do I revert that piece?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
