Re: REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: REINDEX CONCURRENTLY 2.0
Date
Msg-id CA+TgmobeFo3sc1pgjfqYpy2hMkhs5mazP+P5nExKDmdiARL58Q@mail.gmail.com
Whole thread Raw
In response to Re: REINDEX CONCURRENTLY 2.0  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Mon, Feb 2, 2015 at 9:10 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-11-12 16:11:58 -0500, Robert Haas wrote:
>> On Wed, Nov 12, 2014 at 4:10 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> > On Thu, Nov 6, 2014 at 9:50 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> >> If REINDEX cannot work without an exclusive lock, we should invent some
>> >> other qualifier, like WITH FEWER LOCKS.
>> >
>> > What he said.
>>
>> But more to the point .... why, precisely, can't this work without an
>> AccessExclusiveLock?  And can't we fix that instead of setting for
>> something clearly inferior?
>
> So, here's an alternative approach of how to get rid of the AEL
> locks. They're required because we want to switch the relfilenodes
> around. I've pretty much no confidence in any of the schemes anybody has
> come up to avoid that.
>
> So, let's not switch relfilenodes around.
>
> I think if we should instead just use the new index, repoint the
> dependencies onto the new oid, and then afterwards, when dropping,
> rename the new index one onto the old one. That means the oid of the
> index will change and some less than pretty grovelling around
> dependencies, but it still seems preferrable to what we're discussing
> here otherwise.
>
> Does anybody see a fundamental problem with that approach?

I'm not sure whether that will work out, but it seems worth a try.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Unnecessary pointer-NULL checks in pgp-pgsql.c
Next
From: Tom Lane
Date:
Subject: Re: Getting rid of wal_level=archive and default to hot_standby + wal_senders