On 10/8/12 5:08 PM, Andres Freund wrote:
On Monday, October 08, 2012 11:57:46 PM Jim Nasby wrote:
>On 10/5/12 9:57 PM, Michael Paquier wrote:
> >In the current version of the patch, at the beginning of process a new
> >index is created. It is a twin of the index it has to replace, meaning
> >that it copies the dependencies of old index and creates twin entries of
> >the old index even in pg_depend and pg_constraint also if necessary. So
> >the old index and the new index have exactly the same data in catalog,
> >they are completely decoupled, and you do not need to worry about the
> >OID replacements and the visibility consequences.
>
>Yeah, what's the risk to renaming an index during concurrent access? The
>only thing I can think of is an "old" backend referring to the wrong index
>name in an elog. That's certainly not great, but could possibly be dealt
>with.
We cannot have two indexes with the same oid in the catalog, so the two
different names will have to have different oids. Unfortunately the indexes oid
is referred to by other tables (e.g. pg_constraint), so renaming the indexes
while differering in the oid isn't really helpful :(...
Hrm... the claim was made that everything relating to the index, including
pg_depend and pg_contstraint, got duplicated. But I don't know how you could
duplicate a constraint without also playing name games. Perhaps name games are
being played there as well...
Right now I don't see anything that would make switching oids easier than
relfilenodes.
Yeah... in order to make either of those schemes work I think there would need
to non-trivial internal changes so that we weren't just passing around raw
OIDs/filenodes.
BTW, it occurs to me that this problem might be easier to deal with if we had
support for accessing the catalog with the same snapshot as the main query was
using... IIRC that's been discussed in the past for other issues.
--
Jim C. Nasby, Database Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
