Re: Bug in pg_dump/restore -o

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in pg_dump/restore -o
Date: 2002-01-18 04:14:03
Message-ID: 200201180414.g0I4E3509586@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Philip Warner wrote:
> At 21:05 17/01/02 -0500, Tom Lane wrote:
> >
> >A potentially more serious problem is that if the archiving code chooses
> >to issue other operations between the schema restore and data restore
> >for the temp table, we might do a \connect and lose the temp table.
>
> Why is this a problem - I presume I don't understand the OID allocation stuff.

The problem is that if you split the creation of the temp table from the
actual COPY that loads the data, and there is a reconnection to the
server in between, the temp table is automatically deleted, causing the
COPY to fail.

The trick with this oid setting is the temp table COPY should happen
_before_ the schema is created. This way, the pg_class.oid of the newly
created schema doesn't match any of the loaded oid's. Now, you can say
that the oid counter could wrap around, and that is true, but until we
go with the pg_class.oid/table.oid 8-byte unique oid, I would like to
keep the oid unique if possible.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-01-18 04:14:18 Re: UPDATE Query problem
Previous Message Philip Warner 2002-01-18 04:13:15 Re: Bug in pg_dump/restore -o