Re: Potential GIN vacuum bug

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Heikki <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Potential GIN vacuum bug
Date: 2015-08-18 04:11:51
Message-ID: CAMkU=1xMrbDTiYJZn_iRj3p17Awpyp9T8t7Zrgeyyi9Uoi879w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 17, 2015 at 3:02 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Victor Wagner 2015-08-18 04:18:50 Proposal: Implement failover on libpq connect level.
Previous Message Amit Kapila 2015-08-18 03:46:23 Re: checkpointer continuous flushing