Re: GIN fast insert

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GIN fast insert
Дата
Msg-id 28226.1237907970@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GIN fast insert  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: GIN fast insert
Список pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
> Oops, I was wrong, I supposed that all pages in chunk should be lossy, but it's 
> true only for chunk page. So, tbm_add_page() should only call 
> tbm_mark_page_lossy()...

OK, thanks, that's what I thought.  I've changed it in the copy I'm
editing here.

I have another question.  I added the following comment to
ginInsertCleanup(); is it accurate?  (If it isn't, I think
the code is buggy ...)

* This can be called concurrently by multiple backends, so it must cope.* On first glance it looks completely not
concurrent-safeand not crash-safe* either.  The reason it's okay is that multiple insertion of the same entry* is
detectedand treated as a no-op by gininsert.c.  If we crash after* posting entries to the main index and before
removingthem from the* pending list, it's okay because when we redo the posting later on, nothing* bad will happen.
Likewise,if two backends simultaneously try to post* a pending entry into the main index, one will succeed and one will
do*nothing.  We try to notice when someone else is a little bit ahead of* us in the process, but that's just to avoid
wastingcycles.  Only the* action of removing a page from the pending list really needs exclusive* lock.
 

        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Re: GIN fast insert
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: GIN fast insert