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
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 |