Re: Bug in pg_dump/restore -o
От | Bruce Momjian |
---|---|
Тема | Re: Bug in pg_dump/restore -o |
Дата | |
Msg-id | 200201180436.g0I4aW412623@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Bug in pg_dump/restore -o (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bug in pg_dump/restore -o
|
Список | 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 по дате отправления: