Tom Lane <tgl@sss.pgh.pa.us> writes:
> Gregory Stark <stark@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 be a huge run of consecutive OIDs *in the same
> table*.
Really? Wouldn't all it take be a single large COPY loading data into a table
with one or more columns receiving large data which need to be toasted?
> 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.
Well there's a pretty wide margin between millions and 4 billion. I suppose
you could say it would only be a one-time cost (or a few separate one-time
costs until the oid counter passed the old value). So a few minutes after
doing an in-place upgrade while the oid counter skimmed past all the existing
values would be bearable.
> 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 arguing that it's not
justified, but given that it's about the same degree of complexity either way
it seems clear to me that it's better to do it than not to do it.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!