On 2013/03/30, at 2:33, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-03-29 12:28:59 -0400, Tom Lane
>
>>> - REINDEX CONCURRENTLY:
>>> Imo pretty close to being comittable and pretty useful, but it got
>>> redesigned pretty late and it mostly had review from me and fujii and
>>> it could use a bit more input
>>> => unclear
>>
>> I think this really has no hope of being bulletproof until we have
>> MVCC-based catalog scans. The work up to now has been good exploratory
>> effort, but it's not going to be committable without that
>> infrastructure, IMHO anyway.
>
> I think its fair not to commit it in 9.3, the patch came late and has
> undergone significant issues since then. And there are some things in it
> I am not sure about yet.
> But I am not sure why its only acceptable with MVCC scans? Sure, it
> takes an exclusive lock for a very short time when switching the
> relations, but thats still a huge step up over the status quo:
> * toast indexes currently cannot be created/dropped at all. So you have
> to reindex the table which will need to be locked over the whole time.
> * you currently cannot replace indexes that are referenced by foreign
> keys without doing manual catalog hackery which is definitely unsafe
> * you cannot create constraints that use an index concurrently. Parts of
> that is emulatable by creating the constraint with an existing index,
> but that doesn't help e.g. for exclusion constraints.
> * there's no convenient way to issue CREATE INDEX CONCURRENLTY new_index; DROP
> INDEX CONCURRENTLY old_index; RENAME new_index old_index; for all indexes.
Thanks for the detailed explanation! Just adding that this patch needs more review and attention especially for the
toastpart where multiple indexes are handled.
As it looks that it is too late for 9.3, well let's move it to the next commit fest and work on that in the next
releasecycle.
Thanks,
--
Michael
