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 по дате отправления: