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
>>>
>>
>>
>>
>
>
>