Re: CREATE INDEX CONCURRENTLY?

From: Tim Kane <tim(dot)kane(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>, Michael Banck <michael(dot)banck(at)credativ(dot)de>
Cc: Greg Stark <stark(at)mit(dot)edu>, Mark Woodward <mark(dot)woodward(at)actifio(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CREATE INDEX CONCURRENTLY?
Date: 2015-12-30 11:42:17
Message-ID: CADVWZZ+678hL3G9dLwtMLeca3tv5CQTcSf+ArL14YVgsqBUA0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

This just hit us today... Admittedly on an old cluster still running 9.2,
though I can't see any mention of it being addressed since.

Any chance of getting this on to to-do list?
On Sat, 1 Nov 2014 at 07:45, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> On 31 October 2014 17:46, Michael Banck <michael(dot)banck(at)credativ(dot)de> wrote:
>
> > I wonder whether that is pilot error (fair enough), or whether something
> > could be done about this?
>
> When originally written the constraints were tighter, but have since
> been relaxed.
>
> Even so a CIC waits until all snapshots that can see it have gone. So
> what you observe is correct and known.
>
>
> Can it be changed? Maybe.
>
> CREATE INDEX gets around the wait by using indcheckxmin to see whether
> the row is usable. So the command completes, even if the index is not
> usable by all current sessions.
>
> We perform the wait in a completely different way for CIC, for this
> reason (in comments)
>
> We also need not set indcheckxmin during a concurrent index build,
> because we won't set indisvalid true until all transactions that care
> about the broken HOT chains are gone.
>
> Reading that again, I can't see why we do it that way. If CREATE INDEX
> can exit once the index is built, so could CONCURRENTLY.
>
> ISTM that we could indcheckxmin into an Xid, not a boolean
> For CREATE INDEX, set the indcheckxmin = xid of creating transaction
> For CREATE INDEX CONCURRENTLY set the indcheckxmin = xid of the
> completing transaction
>
> The apparent reason it does this is that the Xmin value used currently
> is the Xmin of the index row. The index row is inserted prior to the
> index being valid so that technique cannot work. So I am suggesting
> for CIC that we use the xid of the transaction that completes the
> index, not the xid that originally created the index row. Plus handle
> the difference between valid and not.
>
> --
> Simon Riggs http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-12-30 12:19:28 Re: Making tab-complete.c easier to maintain
Previous Message Shulgin, Oleksandr 2015-12-30 10:48:35 Re: pg_hba_lookup function to get all matching pg_hba.conf entries