Re: Block level concurrency during recovery
От | Simon Riggs |
---|---|
Тема | Re: Block level concurrency during recovery |
Дата | |
Msg-id | 1224514585.3808.709.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 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.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: