On Tue, May 25, 2010 at 2:22 PM, Steve Singer <ssinger at ca.afilias.info> wrote:
> Brian Fehrle wrote:
>
>> On both the master and the slave, there are zero entries in either
>> sl_log_1 or sl_log_2.
>>>
>> I was wondering the same thing, however doesn't the slave node refuse
>> updates/inserts/deletes via a locking system? There are quite a few
>> people who use the databases and I can't account for all actions by
>> everyone. I will give this sync command a try in a bit, I need to wait
>> on some things before I can give it a try.
>
> The slave should refuse updates to replicated tables except if your run
> EXECUTE SCRIPT, the execute script commands restores the tables on the
> replica to the normal state then runs the SQL in your script.  Once it
> is finished the replica deny triggers get enabled again.
>

unless someone had executed TRUNCATE at some time on the slave... not
sure if that fits in your problem though

>  From what your saying the possible sources of the issues are
>
> 1) There was some sort of issue in initial sync that prevented some rows
> from being replicated and no error was generated (I don't think this is
> likely but there could be a bug somewhere)
>

yes, the one discovered here: http://www.slony.info/bugzilla/show_bug.cgi?id=118

> 2) There is some sort of bug that caused changes to not replicate either
> the trigger didn't fire properly or something got marked as replicated
> when it didn't.  I'd be surprised if your the only one reporting this
> but anything is possible
>

scary! but i don't think this is the case

> 3) Someone ran EXECUTE SCRIP(ONLY ON=?) either with a INSERT on the
> oriigin that wouldn't get replicated or with DELETE on the replica.
>

maybe we wan't to refuse INSERT/UPDATE/DELETE/something else in
EXECUTE SCRIPT (ONLY ON=x)?

> 4) Someone with sufficient privileges connected to either the origin or
> the replica and manipulated things to circumvent the slony triggers
>

vandalism! always a possibility... have you fired someone recently? ;)

> 5) Someone did an ALTER TABLE ... without using execute script leaving
> your replication triggers in a bad state.
>
>

have seen a lot of this and always can figure out something wrong
because sl_status and rows always are in sl_log_x (someone maybe
thought those tables were growing enough and truncate them?)

-- 
Jaime Casanova         www.2ndQuadrant.com
Soporte y capacitación de PostgreSQL