Re: logical changeset generation v6

From: Steve Singer <steve(at)ssinger(dot)info>
To: Steve Singer <steve(at)ssinger(dot)info>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: logical changeset generation v6
Date: 2013-09-27 21:06:59
Message-ID: BLU0-SMTP68BBBE888F1337AEEEA3ECDC290@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)(dot)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
>>>
>>
>>
>>
>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-09-27 21:12:17 Re: [PERFORM] Cpu usage 100% on slave. s_lock problem.
Previous Message Peter Geoghegan 2013-09-27 20:41:02 Re: [PERFORM] Cpu usage 100% on slave. s_lock problem.