On Mon, 2008-10-20 at 18:28 +0400, Teodor Sigaev wrote:
> > * For GIN indexes, we appear to not hold a Cleanup lock during
> > vacuuming, except on root page. That stops new scans from starting, but
> > it doesn't prevent progress of concurrent scans. Doesn't look correct to
> > me... so not sure what strength lock to acquire in each case. Probably
> Why do you think so?
I have questions.
I don't understand why in ginVacuumPostingTreeLeaves() we lock only the
root page for Cleanup and no others. Why do we need to hold Cleanup lock
on the root? If the index is concurrent safe for existing scans, why is
it not safe for new scans also? And the converse: if it is not safe for
new scans, why is it safe for existing scans?
> > need to differentiate between WAL record types so we can tell which to
> > acquire CleanupLock for and which not.
> >
> > * GIST doesn't use CleaupLocks at all. So I'm very unclear here.
> Scan process does not hold any pointer on page now, insertion process holds but
> it tracks changes of page by looking at LSN of page.
Sounds good.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
