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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
17 matches
Mail list logo