Re: Block level concurrency during recovery

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