Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 restoring the
Tom Lane wrote:
> Gregory Stark writes:
> > Tom Lane 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,
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
Bruce Momjian 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.
regards, tom l
Tom Lane wrote:
> Bruce Momjian 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 ht
Bruce Momjian 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 pgsql-hackers mailing list
Robert Treat wrote:
> On Wednesday 18 February 2009 10:47:25 Tom Lane wrote:
> > Gregory Stark writes:
> > > Tom Lane 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 co
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_rese
On Wednesday 18 February 2009 10:47:25 Tom Lane wrote:
> Gregory Stark writes:
> > Tom Lane 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 use
Tom Lane writes:
> Gregory Stark 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 be a huge run of consecutive OIDs
Gregory Stark writes:
> Tom Lane 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 O
Tom Lane 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.
>
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
Robert Haas 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
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
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 th
17 matches
Mail list logo
