Re: GIN fast insert

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GIN fast insert
Date: 2009-03-24 15:19:30
Message-ID: 28226.1237907970@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Teodor Sigaev <teodor(at)sigaev(dot)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-safe and not crash-safe
* either. The reason it's okay is that multiple insertion of the same entry
* is detected and treated as a no-op by gininsert.c. If we crash after
* posting entries to the main index and before removing them 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 wasting cycles. Only the
* action of removing a page from the pending list really needs exclusive
* lock.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2009-03-24 15:39:21 Re: GIN fast insert
Previous Message Teodor Sigaev 2009-03-24 15:13:28 Re: GIN fast insert