From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update |
Date: | 2012-11-26 21:39:39 |
Message-ID: | 19546.1353965979@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2012-10-31 11:41:37 +0530, Amit Kapila wrote:
>> There seems to be a problem in behavior of Create Index Concurrently and Hot
>> Update in HEAD code .
> At pgcon.it I had a chance to discuss with Simon how to fix this
> bug. Please check the attached patches - and their commit messages - for
> the fix and some regression tests.
I looked at this a bit. I am very unhappy with the proposed kluge to
open indexes NoLock in some places. Even if that's safe today, which
I don't believe in the least, any future change in this area could break
it.
I'm a bit inclined to think that DROP INDEX CONCURRENTLY should have an
additional step that somehow marks the pg_index row in a new way that
makes RelationGetIndexList ignore it, and then wait out existing
transactions before taking the final step of dropping the index. The
Right Way to do this would likely have been to add another bool column,
but we don't have that option anymore in 9.2. Maybe we could abuse
indcheckxmin somehow, ie use a state that can't otherwise occur (in
combination with the values of indisvalid/indisready) to denote an index
being dropped.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Karl O. Pinc | 2012-11-26 21:51:05 | Re: Suggestion for --truncate-tables to pg_restore |
Previous Message | David Fetter | 2012-11-26 21:37:17 | Re: Materialized views WIP patch |