Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Дата
Msg-id 1346445756-sup-1463@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Excerpts from Alvaro Herrera's message of vie ago 31 16:25:40 -0400 2012:
> Excerpts from Tom Lane's message of vie ago 31 16:01:03 -0400 2012:
> > Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > > Here's a patch.
> >=20
> > Looks reasonable, but please try a little harder on the comments for =
the
> > new function --- IMO it should have a header comment that explains wh=
at
> > it's supposed to do exactly.
>=20
> Sure.
>=20
> This doesn't actually work though: it's trying to move sequences twice.
> Not sure what the right fix for this is ... still looking.

The error message:

alvherre=3D# alter extension isn set schema foo;
ERROR:  tuple already updated by self

Besides being listed with deptype=3Dextension for the extension in
question, the sequence has a deptype=3Dauto entry for the column, which
leads to it being moved twice.

I don't see any clean fix for this:

1. At extension creation time, skip generating dependencies for
sequences that are part of a table.  I don't see how to do this: We
would have to reach within heap_create_with_catalog and tell it not to
add an deptype=3Dextension dependency if it's called for a sequence that'=
s
part of a serial column.  I don't think heap_create_with_catalog even
knows that at all.

2. During ALTER EXTENSION execution, skip moving objects that have
already been moved.  Not really sure how this would be implemented;
perhaps we could have AlterObjectNamespace_oid add each moved object to
a list of moved objects, and skip everything that's already present in
it.  Seems very messy to implement.

3. Pass a flag to AlterTableNamespaceInternal, something like
"skip_sequences", and do not call AlterSeqsNamespace it that's set.
This seems really ugly though, and I'm not sure if it might break
something else.

4. Maybe we could have AlterRelationNamespaceInternal check what the
current namespace is for the object, and do nothing if it's already the
target namespace.


One thing to keep in mind is that existing databases might already have
broken catalogs (i.e. extensions have already been moved and objects are
already in nonexistant schemas).  This is not very likely unless the
user has not been using pg_dump at all.  But many databases already have
deptype=3Dextension pg_depend entries for sequences owned by SERIAL
columns, so it's unclear that (1) is a good solution even if it were
implementable.

--=20
=C3=81lvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations