Re: REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: REINDEX CONCURRENTLY 2.0
Date
Msg-id 20141114164705.GF11733@alap3.anarazel.de
Whole thread Raw
In response to Re: REINDEX CONCURRENTLY 2.0  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: REINDEX CONCURRENTLY 2.0  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2014-11-13 11:41:18 -0500, Robert Haas wrote:
> On Wed, Nov 12, 2014 at 7:31 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > But I think it won't work realistically. We have a *lot* of
> > infrastructure that refers to indexes using it's primary key. I don't
> > think we want to touch all those places to also disambiguate on some
> > other factor. All the relevant APIs are either just passing around oids
> > or relcache entries.
> 
> I'm not quite following this.  The whole point is to AVOID having two
> indexes.  You have one index which may at times have two sets of
> physical storage.

Right. But how are we going to refer to these different relfilenodes?
All the indexing infrastructure just uses oids and/or Relation pointers
to refer to the index. How would you hand down the knowledge which of
the relfilenodes is supposed to be used in some callchain?

There's ugly solutions like having a flag like 'bool
rd_useotherfilenode' inside struct RelationData, but even ignoring the
uglyness I don't think that'd work well - what if some function called
inside the index code again starts a index lookup?

I think I might just not getting your idea here?

> > And all the
> > indexing infrastructure can't deal with that without having separate
> > oids & relcache entries.

Hopefully explained above?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS
Next
From: Stephen Frost
Date:
Subject: Re: Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS