Re: Bugs in CREATE/DROP INDEX CONCURRENTLY - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Bugs in CREATE/DROP INDEX CONCURRENTLY
Date
Msg-id 005601cdce27$0bed9b60$23c8d220$@kapila@huawei.com
Whole thread Raw
In response to Re: Bugs in CREATE/DROP INDEX CONCURRENTLY  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Thursday, November 29, 2012 4:24 PM Andres Freund wrote:
> On 2012-11-29 16:18:07 +0530, Amit Kapila wrote:
> > On Thursday, November 29, 2012 12:39 AM Tom Lane wrote.
> > > Andres Freund <andres@2ndquadrant.com> writes:
> > > > On 2012-11-27 23:46:58 -0500, Tom Lane wrote:
> > > >> Attached is a very preliminary draft patch for this.  I've not
> > > >> addressed the question of whether we can clear indcheckxmin
> during
> > > >> transactional updates of pg_index rows, but I think it covers
> > > >> everything else talked about in this thread.
> > >
> >
> > > Attached is an updated patch for HEAD that I think is about ready to
> go.
> > > I'll start making a back-patchable version shortly.
> >
> > I had verified in the Patch committed that the problem is resolved.
> >
> > I have a doubt related to RelationGetIndexList() function.
> >
> > In while loop, if index is not live then it continues, so it can be
> possible
> > that we don't find a valid index after this while loop.
> > But still after the loop, it marks relation->rd_indexvalid = 1. I am
> not
> > able to see any problem with it, but why to mark it as valid when
> actually
> > there is no valid index.
> 
> rd_indexvalid is just saying whether rd_indexlist is valid. A zero
> element list seems to be valid to me. If we don't set rd_indexvalid
> pg_index will constantly be rescanned because the result isn't
> considered cached anymore.

Got the point.
Thanks.

With Regards,
Amit Kapila.




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Bugs in CREATE/DROP INDEX CONCURRENTLY
Next
From: Muhammad Usama
Date:
Subject: Patch to fix ecpg core dump with nested structure pointer variable