Re: [HACKERS] pg_migrator progress

2009-03-28 Thread Tom Lane
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: 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. FYI, I decided against

Re: [HACKERS] pg_migrator progress

2009-03-28 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Tom Lane wrote: 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. FYI,

Re: [HACKERS] pg_migrator progress

2009-03-27 Thread Bruce Momjian
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

Re: [HACKERS] pg_migrator progress

2009-02-19 Thread Bruce Momjian
Gregory Stark wrote: 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. Yeah, if it was massive amounts of code I could see

[HACKERS] pg_migrator progress

2009-02-18 Thread Bruce Momjian
I have completed all the outstanding pg_migratory TODO items. I still have more work to do in cleanup and testing, but if people want to look at my progress, now is a good time. You can download the current CVS here: http://pgfoundry.org/scm/?group_id=1000235 and you can subscribe to

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Robert Haas
You've moved fast on this! #ifdef NOT_USED /* 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

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Tom Lane
Robert Haas robertmh...@gmail.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

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Alvaro Herrera
Bruce Momjian wrote: I have completed all the outstanding pg_migratory TODO items. I still have more work to do in cleanup and testing, but if people want to look at my progress, now is a good time. Hmm, don't you need to change the Xid counter (pg_resetxlog) if you're going to mess with

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Gregory Stark
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

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Tom Lane
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

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Gregory Stark
Tom Lane t...@sss.pgh.pa.us writes: Gregory Stark st...@enterprisedb.com writes: 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

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Robert Treat
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

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Bruce Momjian
Alvaro Herrera wrote: Bruce Momjian wrote: I have completed all the outstanding pg_migratory TODO items. I still have more work to do in cleanup and testing, but if people want to look at my progress, now is a good time. Hmm, don't you need to change the Xid counter (pg_resetxlog) if

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Bruce Momjian
Robert Treat wrote: 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

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Tom Lane
Bruce Momjian br...@momjian.us writes: One compromise is outputting the pg_resetxlog command to the terminal, and suggesting they run it only if they need to. Er, what? pg_resetxlog is certainly not optional in this process. regards, tom lane -- Sent via

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: One compromise is outputting the pg_resetxlog command to the terminal, and suggesting they run it only if they need to. Er, what? pg_resetxlog is certainly not optional in this process. The oid setting part is. -- Bruce Momjian

Re: [HACKERS] pg_migrator progress

2009-02-18 Thread Tom Lane
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: Er, what? pg_resetxlog is certainly not optional in this process. The oid setting part is. Yeah, but if you have to run it anyway it certainly isn't going to be any more work to make it set the OID counter too.