On Mon, 2008-10-20 at 20:12 +0400, Teodor Sigaev wrote: > > 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? > > Because we wish to prevent concurrent inserts and page deletion just to > simplify > code. LockForCleanup guarantees that insertion process is not work here (it > keeps root buffer pinned all time of insertion). New scan processes can't > start > as a side effect.
But does holding cleanup lock on root prevent an in-progress Insert from changing non-root pages? I assume so, just not sure how. > Note, in most cases it keeps enough concurrence because all that is about > work > on one tree in GIN index. Usually, there is a lot of such trees in index - > for > each lexeme if we speak about tsearch index. So, there is a place for > improvements but I don't believe that will give a big advantage for > performance > in typical usage of GIN. I'm just worried about safety during Hot Standby, not trying to improve anything. -- 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
