On Sat, 22 Jul 2006 05:19:14 -0400
Jan Wieck <JanWieck at Yahoo.com> wrote:
 
> Please get me the output of the following two queries for any table 
> where this still occurs:

Attached.. 

> as well as a full schema description of the table, including primary 
> keys, unique and not null constraints. 

I have attached the output of 'pg_dump -s -t User laterooms' - is this all that is required?

The Booking table is probably more important, but I am interested to hear your views on the data from the User table - hopefully then I'll be able to learn and apply the same technique to the Booking table.

In fact, given that I've dropped Booking from replication, it might even be likely that it 'fixes itself' when I add a new temporary set, then merge back into set 1.

> The only way I could imagine how slony got into that stage is that you 
> have executed DDL like ALTER TABLE DROP COPUMN directly while the table 
> was replicated (directly meaning not done via EXECUTE SCRIPT). Doing so 
> would get the key attributes out of sync with respect to their position 
> within all non-attisdroped columns.

Interesting, it's entirely possible, but the thing that doesn't make sense is why this only started happening at 4am this morning, just after the nightly backups + vacuum :)

Cheers,
Gavin.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pg_attribute.txt
Url: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060722/38b6fede/pg_attribute-0001.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: user-schema.txt
Url: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060722/38b6fede/user-schema-0001.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pg_trigger.txt
Url: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060722/38b6fede/pg_trigger-0001.txt