Andrew Sullivan <ajs at crankycanuck.ca> writes:
> On Fri, Jun 29, 2007 at 03:25:00PM -0700, Bill Willits wrote:
>> 
>> Can you explain if this is dependant on some version of PG or Slony?  Or, 
>
> PostgreSQL pg_dump prior to, I think, 8.1 (it might be 8.0) are not
> quite as aggressive in checking for some of these errors, so you
> don't get them when you dump the database.  Unfortunately, you get
> garbage dumps.  When you restore, you run a serious risk of running
> into problems you didn't know you could have.  This is because the
> catalogue tables have been messed with by Slony.  So, any database
> that has even _one_ replicated table in it (i.e. not the origin for
> every table) should never be dumped using pg_dump.

There are two mods to be made to that "never"...

1.  It isn't true of the origin node.  On the origin node, the schema
isn't actually broken (because we aren't hiding triggers/rules).  You
*can*, *always*, run pg_dump successfully against the origin.

2.  The problem is with the system catalogue on the subscribers.  If
you run "pg_dump -a", to dump data only, it doesn't run into the
catalogue problem.

In Slony-I 2.0, on PG 8.3, this is all alleviated.  You can take a
pg_dump of a subscriber node and it will both work (e..g. - pg_dump
won't crash due to noticing busted catalogue info) and be consistent.
-- 
select 'cbbrowne' || '@' || 'ca.afilias.info';
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)