Re: Potential GIN vacuum bug - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Potential GIN vacuum bug
Date
Msg-id CAMkU=1xMrbDTiYJZn_iRj3p17Awpyp9T8t7Zrgeyyi9Uoi879w@mail.gmail.com
Whole thread Raw
In response to Re: Potential GIN vacuum bug  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Mon, Aug 17, 2015 at 3:02 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Jeff Janes wrote:

> The attached patch takes a ShareUpdateExclusiveLock lock on the index in
> order to clean the pending list.

Does it take a lock on the table also?  Because if not ...

There must be some kind of lock held on the table already (either RowExclusive at least for user backends or ShareRowExclusive for vacuum backends), but I don't do anything in this patch with it.
 

> One potential problem is how it will interact with "create index
> concurrently".

... then I don't understand how you could have a problem here.  Surely
no pending list cleanup can happen concurrently with the index being
created?

While grepping through the code looking for precedent, I noticed that "create index concurrently" takes a ShareUpdateExclusiveLock on both table and index. I don't know why it needs one on the index, I didn't investigate it thoroughly.

During the last stage of the "create index concurrently", inserters and updaters are obliged to maintain the index even though they can't use it yet.  So that would mean adding to the pending list, which might get big enough to need cleaning.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: checkpointer continuous flushing
Next
From: Victor Wagner
Date:
Subject: Proposal: Implement failover on libpq connect level.