Re: Ever increasing OIDs - gonna run out soon?

We'll probably upgrade to 8.1.x before we hit the wraparound problem! :)

Hmm, looks like slony uses OIDs... And I found a couple of my own tables
which were incorrectly created with OIDs.

select relname, relnamespace, reltype from pg_catalog.pg_class where
relhasoids=true;


     relname     | relnamespace | reltype
----------------+--------------+----------
  pg_attrdef     |           11 |    16385
  pg_constraint  |           11 |    16387
  pg_database    |           11 |       88
  pg_proc        |           11 |       81
  pg_rewrite     |           11 |    16411
  pg_type        |           11 |       71
  pg_class       |           11 |       83
  pg_operator    |           11 |    16393
  pg_opclass     |           11 |    16395
  pg_am          |           11 |    16397
  pg_language    |           11 |    16403
  pg_trigger     |           11 |    16413
  pg_cast        |           11 |    16419
  pg_namespace   |           11 |    16596
  pg_conversion  |           11 |    16598
  sturllog       |        18161 |    18519  <-- MINE
  stsession      |        18161 |    18504
  sl_trigger     |     82061042 | 82061126  <-- SLONY
  sl_table       |     82061042 | 82061113
  sl_nodelock    |     82061042 | 82061082
  sl_setsync     |     82061042 | 82061098
  sl_sequence    |     82061042 | 82061134
  sl_node        |     82061042 | 82061073
  sl_listen      |     82061042 | 82061162
  sl_path        |     82061042 | 82061147
  sl_subscribe   |     82061042 | 82061174
  sl_set         |     82061042 | 82061087
  sl_event       |     82061042 | 82061186
  sl_confirm     |     82061042 | 82061193
  sl_seqlog      |     82061042 | 82061198
  sl_log_1       |     82061042 | 82061202
  sl_log_2       |     82061042 | 82061209
  sl_config_lock |     82061042 | 82061229

Thanks

John

Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
>
>>Well, you have to be using a lot of OIDs for this to be an issue. At
>>your stated rate of 1.5 million OIDs per day it will take just under
>>eight years before you wraparound. That's a lot of OIDs and most
>>databases don't get anywhere near that many, which is why it's not a
>>big deal for most people...
>
>
> It should also be pointed out that OID wraparound is not a fatal
> condition.  Pre-8.1 you might get occasional query failures due to
> trying to insert duplicate OIDs, but that's about it.
>
>
>>This gives you a list of tables that use OIDs. Maybe it can help you
>>track down the problem.
>
>
> Look at pg_class.relhasoids --- easier, and more reliable.
>
>             regards, tom lane