Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Jeff <threshar(at)threshar(dot)is-a-geek(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Date: 2009-08-06 08:32:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> preventing a clash might be fairly difficult.
> Yeah, I was just thinking about that. The easiest way to avoid
> collisions would be to make pg_dump (in --binary-upgrade mode)
> responsible for being sure that *every* new pg_type and pg_class row
> OID matches what it was in the old DB.

As we already have WITH OIDS for CREATE TABLE command, maybe adding
support for WITH OID ... to the necessary commands would do the trick?

Instead of messing with pg_type, pg_dump would then have to issue a OID
'decorated' command such as
CREATE TYPE footype ... WITH OID 27604;

> We could stop doing that
> once we have all the user tables in place --- I don't believe it's
> necessary to preserve the OIDs of user indexes. But we need to
> preserve toast table OIDs, and toast table index OIDs too if those
> are created at the same time they are now (else we risk one of them
> colliding with a toast table OID we want to create later).

It seems harder to come up with a general purpose syntax to support the
feature in case of toast tables, though.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Boszormenyi Zoltan 2009-08-06 09:07:59 Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Previous Message Magnus Hagander 2009-08-06 07:30:35 Re: 8.4 win32 shared memory patch