Subject: Re: REINDEX CONCURRENTLY 2.0
To: Jim Nasby <Jim.Nasby@BlueTreble.com>,
 Michael Paquier <michael.paquier@gmail.com>,
 PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
References: 
 <CAB7nPqSTFkuc7dZxCDX4HOTU63YXHRroNv2aoUzyD-Zz_8Z_Zg@mail.gmail.com>
 <a8e56251-bd3c-521e-7a2c-35d66b5f7f29@proxel.se>
 <af867d20-1406-38c0-0a58-2cf1fce7240f@BlueTreble.com>
From: Andreas Karlsson <andreas@proxel.se>
Message-ID: <3ed671c8-0b03-e42a-710e-b50bb91b79fe@proxel.se>
Date: Fri, 3 Mar 2017 03:44:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: <af867d20-1406-38c0-0a58-2cf1fce7240f@BlueTreble.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 03/02/2017 02:25 AM, Jim Nasby wrote:
> On 2/28/17 11:21 AM, Andreas Karlsson wrote:
>> The only downside I can see to this approach is that we no logner will
>> able to reindex catalog tables concurrently, but in return it should be
>> easier to confirm that this approach can be made work.
>
> Another downside is any stored regclass fields will become invalid.
> Admittedly that's a pretty unusual use case, but it'd be nice if there
> was at least a way to let users fix things during the rename phase
> (perhaps via an event trigger).

Good point, but I agree with Andres here. Having REINDEX CONCURRENTLY 
issue event triggers seems strange to me. While it does create and drop 
indexes as part of its implementation, it is actually just an index 
maintenance job.

Andreas


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers