Moving to slony1-general...

Hmm... is sl_trigger intentionally created WITH OIDs?

On Mon, Jun 12, 2006 at 08:05:05PM +0100, John Sidney-Woollett wrote:
> 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 at 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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
> 

-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby at pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461