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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
