Re: remove spurious CREATE INDEX CONCURRENTLY wait

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, James Coleman <jtc331(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: remove spurious CREATE INDEX CONCURRENTLY wait
Date: 2020-11-09 15:47:43
Message-ID: 20201109154743.sij6j5ue3j673r7h@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On Tue, Nov 03, 2020 at 07:14:47PM +0100, Dmitry Dolgov wrote:
> > On Thu, Aug 20, 2020 at 03:11:19PM +0900, Michael Paquier wrote:
> > On Wed, Aug 19, 2020 at 02:16:46PM -0400, Alvaro Herrera wrote:
> > > I did not set the flag in REINDEX CONCURRENTLY, but as I understand it
> > > can be done too, since in essence it's the same thing as a CIC from a
> > > snapshot management point of view.
> >
> > Yes, I see no problems for REINDEX CONCURRENTLY as well as long as
> > there are no predicates and expressions involved. The transactions
> > that should be patched are all started in ReindexRelationConcurrently.
> > The transaction of index_concurrently_swap() cannot set up that
> > though. Only thing to be careful is to make sure that safe_flag is
> > correct depending on the list of indexes worked on.
> Hi,
> After looking through the thread and reading the patch it seems good,
> and there are only few minor questions:
> * Doing the same for REINDEX CONCURRENTLY, which does make sense. In
> fact it's already mentioned in the commentaries as done, which a bit
> confusing.

Just to give it a shot, would the attached change be enough?

Attachment Content-Type Size
v3-0001-Avoid-spurious-CREATE-INDEX-CONCURRENTLY-waits.patch text/x-diff 9.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2020-11-09 15:58:06 Re: abstract Unix-domain sockets
Previous Message Dmitry Shulga 2020-11-09 15:44:25 Re: Reduce the time required for a database recovery from archive.