From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: src/test/subscription/t/005_encoding.pl is broken |
Date: | 2017-09-19 12:02:32 |
Message-ID: | CAB7nPqT44Nxaat2UAnrz+noe74fVz7Dv6UzRvY6oMo-+SJPrrA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 19, 2017 at 8:51 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Sep 18, 2017 at 1:58 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> To my knowledge here's not really any difference between the two in
>> logical replication. Received changes are immediately applied, there's
>> no equivalent to a walreceiver queing up "logical wal" onto disk.
>
> Huh? Decoding and applying the changes has to take some finite time
> greater than 0.
FWIW, the wait method looks fine to me.
Now, I just had a look at the logs for a failure and a success, and
one difference can be seen in the subscriber's logs as follows:
-LOG: logical replication table synchronization worker for
subscription "mysub", table "test1" has started
-LOG: logical replication table synchronization worker for
subscription "mysub", table "test1" has finished
+WARNING: out of background worker slots
+HINT: You might need to increase max_worker_processes.
The "+" portion is for a failure, and I think that this causes the
subscription to not consume the changes from the publisher which
explains the failure in the test as the logical worker applying the
changes on the subscriber-side is not here.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2017-09-19 12:11:52 | Re: [PATCH] Generic type subscripting |
Previous Message | Robert Haas | 2017-09-19 11:51:25 | Re: src/test/subscription/t/005_encoding.pl is broken |