Skip site navigation (1) Skip section navigation (2)

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
Message-ID: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group