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

Re: Migration \ OID question

From: "Lipker, Joseph" <Joseph(dot)Lipker(at)WRECO1(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Migration \ OID question
Date: 2008-12-22 18:07:21
Message-ID: C10317901E94094383071D851A6272E3038AA516C9@WAFEDIXMCMS14.corp.weyer.pri (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Thanks Tom.

Unfortunately, none of the tables oid column have a unique index on them at this time. Will add them to adjust for this.

You mentioned "performance glitches". What would those be? Errors or system performance slowdowns.

Joseph Lipker
>Weyerhaeuser Real Estate Company - IT Department
>Federal Way, WA 98063-9777
>Office: 253-924-5994
Cell: 253-249-6819

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Friday, December 19, 2008 8:02 PM
To: Lipker, Joseph
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] Migration \ OID question

"Lipker, Joseph" <Joseph(dot)Lipker(at)WRECO1(dot)com> writes:
> The application I inherited relies upon the oid's for primary keys.

It'd be a good idea to move away from that.

> The question is, after reloading the 7.2 version into the 8.19 version, should the migrated database be starting with the 203199999 as last oid and then assign 203200000 as the next oid?


> What I am concerned about is when the 8.1.9 version assigns an oid that already exists.

If you have a unique index on the table's OID column (as one would hope, else it's not good for much) then 8.1 and up will avoid assigning duplicate OIDs.  There might be some performance glitches if you have very long runs of consecutive OIDs in the same table, though.

                        regards, tom lane

In response to


pgsql-admin by date

Next:From: Tom LaneDate: 2008-12-23 04:50:52
Subject: Re: Psql errors
Previous:From: Tom LaneDate: 2008-12-22 16:56:45
Subject: Re: publishing changelogs on pgweb

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