| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_migrator progress |
| Date: | 2009-02-18 15:20:37 |
| Message-ID: | 6751.1234970437@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> /* XXX do we need this at all? */
>> /*
>> * Assuming OIDs are only used in system tables, there is no need to
>> * restore the OID counter because we have not transfered any OIDs
>> * from the old system.
>> */
> It's certainly not impossible for someone to be using OIDs on user
> tables, is it?
No, but this would just be the same situation that prevails after
OID-counter wraparound, so I don't see a compelling need for us to
change the OID counter in the new DB. If the user has done the Proper
Things (ie, made unique indexes on his OIDs) then it won't matter.
If he didn't, his old DB was a time bomb anyway.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adriano Lange | 2009-02-18 15:22:02 | graph representation of data structures in optimizer |
| Previous Message | Sam Mason | 2009-02-18 15:13:44 | Re: The science of optimization in practical terms? |