Re: Block level concurrency during recovery

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block level concurrency during recovery
Date: 2008-10-20 16:12:34
Message-ID: 48FCADF2.8010609@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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.

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.

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-10-20 17:14:14 Re: SQL:2008 LIMIT/OFFSET
Previous Message Teodor Sigaev 2008-10-20 15:47:28 Re: Index use during Hot Standby