Re: Support for REINDEX CONCURRENTLY

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Support for REINDEX CONCURRENTLY
Date: 2013-08-28 13:02:52
Message-ID: 20130828130252.GA5181@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-08-28 13:58:08 +0900, Michael Paquier wrote:
> On Tue, Aug 27, 2013 at 11:09 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > On 2013-08-27 15:34:22 +0900, Michael Paquier wrote:
> >> I have been working a little bit more on this patch for the next
> >> commit fest. Compared to the previous version, I have removed the part
> >> of the code where process running REINDEX CONCURRENTLY was waiting for
> >> transactions holding a snapshot older than the snapshot xmin of
> >> process running REINDEX CONCURRENTLY at the validation and swap phase.
> >> At the validation phase, there was a risk that the newly-validated
> >> index might not contain deleted tuples before the snapshot used for
> >> validation was taken. I tried to break the code in this area by
> >> playing with multiple sessions but couldn't. Feel free to try the code
> >> and break it if you can!
> >
> > Hm. Do you have any justifications for removing those waits besides "I
> > couldn't break it"? The logic for the concurrent indexing is pretty
> > intricate and we've got it wrong a couple of times without noticing bugs
> > for a long while, so I am really uncomfortable with statements like this.
> Note that the waits on relation locks are not removed, only the wait
> phases involving old snapshots.
>
> During swap phase, process was waiting for transactions with older
> snapshots than the one taken by transaction doing the swap as they
> might hold the old index information. I think that we can get rid of
> it thanks to the MVCC snapshots as other backends are now able to see
> what is the correct index information to fetch.

I don't see MVCC snapshots guaranteeing that. The only thing changed due
to them is that other backends see a self consistent picture of the
catalog (i.e. not either, neither or both versions of a tuple as
earlier). It's still can be out of date. And we rely on those not being
out of date.

I need to look into the patch for more details.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-08-28 13:16:14 Re: Valgrind Memcheck support
Previous Message Kohei KaiGai 2013-08-28 12:17:19 Re: [v9.4] row level security