On 09/26/2013 02:47 PM, 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.
If force it to restart replication from 0/A9320B00 I see datarows that
I appear to have already seen before the restart.
I think this is happening when I process the data for 0/A9320B00 but
don't get the feedback message my slon was killed. Is this expected?
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.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
