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@xxxxxxxxx> 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
