On 2012-11-27 14:08:13 -0500, Tom Lane wrote:
> BTW, I was thinking that the DROP INDEX CONCURRENTLY logic needed to be:
>
> 1. Unset indisvalid, commit, wait out all reading transactions.
>
> 2. Unset indisready, commit, wait out all writing transactions.
>
> 3. Unset indislive, commit (with paren
On 2012-11-27 12:50:36 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I vote for introducing wrapper functions/macro to do the
> > about-to-be-dropped check, its hard enough to understand as-is.
>
> Meh. If it's only going to be done in RelationGetIndexList, I'm
> not sure that a wrapper macr
On 2012-11-27 12:02:09 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2012-11-26 16:39:39 -0500, Tom Lane wrote:
> >> 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
On Tue, Nov 27, 2012 at 12:02 PM, Tom Lane wrote:
> The point of not wanting to open the index NoLock (and for that matter
> of having DROP INDEX CONCURRENTLY take AccessExclusiveLock once it
> thinks nobody is touching the index) is to make sure that if somehow
> somebody is touching the index an
Andres Freund writes:
> On 2012-11-26 16:39:39 -0500, Tom Lane wrote:
>> 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.
On Tue, Nov 27, 2012 at 4:49 PM, Andres Freund wrote:
> On 2012-11-27 16:39:58 +0530, Pavan Deolasee wrote:
>
> > >
> > There might be a bug there as you are suggesting, but for me the CREATE
> > INDEX itself fails (and rightly so) because of duplicate keys. Do I need
> to
> > run these statements
On Tue, Nov 27, 2012 at 11:38 AM, Tom Lane wrote:
> Pavan Deolasee writes:
> > On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane wrote:
> >> Either state of indcheckxmin is valid with all three of these
> >> combinations, so the specific kluge I was contemplating above doesn't
> >> work. But there is
On 2012-11-27 16:39:58 +0530, Pavan Deolasee wrote:
> On Tue, Nov 27, 2012 at 4:22 PM, Andres Freund wrote:
>
> > On 2012-11-27 11:48:08 +0100, Andres Freund wrote:
> >
> > >
> > > I haven't yet looked deeply enough to judge whether there are actually
> > > bugs. But I can say that the e.g. the mi
On Tue, Nov 27, 2012 at 4:22 PM, Andres Freund wrote:
> On 2012-11-27 11:48:08 +0100, Andres Freund wrote:
>
> >
> > I haven't yet looked deeply enough to judge whether there are actually
> > bugs. But I can say that the e.g. the missing indisvalid checks in
> > transformFkeyCheckAttrs makes me pr
On 2012-11-27 11:52:11 +0100, Andres Freund wrote:
> On 2012-11-27 11:48:08 +0100, Andres Freund wrote:
> > On 2012-11-27 10:18:37 +0530, Pavan Deolasee wrote:
> > > On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane wrote:
> > >
> > > > I wrote:
> > > >
> > > > Either state of indcheckxmin is valid with a
On 2012-11-27 11:48:08 +0100, Andres Freund wrote:
> On 2012-11-27 10:18:37 +0530, Pavan Deolasee wrote:
> > On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane wrote:
> >
> > > I wrote:
> > >
> > > Either state of indcheckxmin is valid with all three of these
> > > combinations, so the specific kluge I was
On 2012-11-27 10:18:37 +0530, Pavan Deolasee wrote:
> On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane wrote:
>
> > I wrote:
> >
> > Either state of indcheckxmin is valid with all three of these
> > combinations, so the specific kluge I was contemplating above doesn't
> > work. But there is no valid rea
On 2012-11-26 22:31:50 -0500, Tom Lane wrote:
> I wrote:
> > 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
On 2012-11-26 16:39:39 -0500, Tom Lane wrote:
> Andres Freund 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 t
Pavan Deolasee writes:
> On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane wrote:
>> Either state of indcheckxmin is valid with all three of these
>> combinations, so the specific kluge I was contemplating above doesn't
>> work. But there is no valid reason for an index to be in this state:
>> indisvali
On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane wrote:
> I wrote:
>
> Either state of indcheckxmin is valid with all three of these
> combinations, so the specific kluge I was contemplating above doesn't
> work. But there is no valid reason for an index to be in this state:
>
> indisvalid = true, indi
On Tue, Nov 27, 2012 at 12:31 PM, Tom Lane wrote:
> I wrote:
> > 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
I wrote:
> 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
> Rig
Andres Freund 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
Hi,
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
20 matches
Mail list logo
