Hi Steve,
On 2013-09-27 17:06:59 -0400, Steve Singer wrote:
> >I've determined that when in this test the walsender seems to be hitting
> >this when it is decode the transactions that are behind the slonik
> >commands to add tables to replication (set add table, set add sequence).
> >This is before the SUBSCRIBE SET is submitted.
> >
> >I've also noticed something else that is strange (but might be unrelated).
> >If I stop my slon process and restart it I get messages like:
> >
> >WARNING: Starting logical replication from 0/a9321360
> >ERROR: cannot stream from 0/A9321360, minimum is 0/A9320B00
> >
> >Where 0/A9321360 was sent in the last packet my slon received from the
> >walsender before the restart.
Uh, that looks like I fumbled some comparison. Let me check.
> I've further narrowed this down to something (or the combination of) what
> the _disorder_replica.altertableaddTriggers(1);
> stored function does. (or @SLONYNAMESPACE@.altertableaddTriggers(int);
>
> Which is essentially
> * Get an exclusive lock on sl_config_lock
> * Get an exclusive lock on the user table in question
> * create a trigger (the deny access trigger)
> * create a truncate trigger
> * create a deny truncate trigger
>
> I am not yet able to replicate the error by issuing the same SQL commands
> from psql, but I must be missing something.
>
> I can replicate this when just using the test_decoding plugin.
Thanks. That should get me started with debugging. Unless it's possibly
fixed in the latest version, one bug fixed there might cause something
like this if the moon stands exactly right?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services