On Wednesday 18 February 2009 10:47:25 Tom Lane wrote: > Gregory Stark <st...@enterprisedb.com> writes: > > Tom Lane <t...@sss.pgh.pa.us> writes: > >> 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. > > > > Also I wonder about the performance of skipping over thousands or even > > millions of OIDs for something like a toast table. > > I think that argument is a red herring. In the first place, it's > unlikely that there'd be a huge run of consecutive OIDs *in the same > table*. In the second place, if he does have such runs, the claim that > he can't possibly have dealt with OID wraparound before seems pretty > untenable --- he's obviously been eating lots of OIDs. >
Yeah, but its not just lots... it's lots and lots of lots. Sure, I have multi-billion row _tables_ now, but I know I ran systems for years "back in the day" when we used oids in user tables, and they never made it to oid wraparound terratory, because they just didn't churn through that much data. > But having said that, there isn't any real harm in fixing the OID > counter to match what it was. You need to run pg_resetxlog to set the > WAL position and XID counter anyway, and it can set the OID counter too. > +1 for doing this, otherwise we need some strong warnings in the migrator docs about this case imho. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
