Re: Block level concurrency during recovery
От | Simon Riggs |
---|---|
Тема | Re: Block level concurrency during recovery |
Дата | |
Msg-id | 1224523938.3808.784.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Block level concurrency during recovery (Teodor Sigaev <teodor@sigaev.ru>) |
Ответы |
Re: Block level concurrency during recovery
|
Список | pgsql-hackers |
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.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: