Re: Bug in pg_dump/restore -o - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Bug in pg_dump/restore -o
Date
Msg-id 200201180436.g0I4aW412623@candle.pha.pa.us
Whole thread Raw
In response to Re: Bug in pg_dump/restore -o  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bug in pg_dump/restore -o  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Given a pg_dump archive containing OIDs, I would expect a schema-only
> >> pg_restore followed by a data-only pg_restore to produce the same end
> >> result as a schema+data restore, no?
> 
> > That is the big question, if they are doing a schema-only restore, will
> > then then do a data-only restore, or will they not.  My guess is that
> > they will not or they would have just restored the whole thing.
> 
> > The downside of setting the oid counter on schema-only is that you have
> > set the counter much higher than they may have wanted, especially if
> > they are doing the schema-only restore to somehow get the counter down
> > again.  The downside of _not_ setting the oid counter on schema-only is
> > that they may have duplicate oids between system and user tables.  That
> > seems less of a risk than the former, and much less likely to happen.
> 
> Good points.  So I guess you are saying it would be okay to treat the
> setMaxOid TOC item as data, and have it appear only in schema+data or
> data-only restores.  In that case, back to plan A.

Yes, that was my proposal.  I was consindering a case where the load the
schema just to populate a fresh database that is to be used by the
application.  In such cases, setting the oid makes little sense.

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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Bug in pg_dump/restore -o
Next
From: Bruce Momjian
Date:
Subject: pg_upgrade