On 2017-02-16 00:43, Petr Jelinek wrote:
> On 13/02/17 14:51, Erik Rijkers wrote:
>> On 2017-02-11 11:16, Erik Rijkers wrote:
>>> On 2017-02-08 23:25, Petr Jelinek wrote:
>>>
>>>> 0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
>>>> 0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
>>>> 0003-Fix-after-trigger-execution-in-logical-replication-v2.patch
>>>> 0004-Add-RENAME-support-for-PUBLICATIONs-and-SUBSCRIPTION-v2.patch
>>>> 0001-Logical-replication-support-for-initial-data-copy-v4.patch
>>>
>>> This often works but it also fails far too often (in my hands). I
>
> That being said, I am so far having problems reproducing this on my
> test
> machine(s) so no idea what causes it yet.
>
A few extra bits:
- I have repeated this now on three different machines (debian 7, 8,
centos6; one a pretty big server); there is always failure within a few
tries of that test program (i.e. pgbench_derail2.sh, with the above 5
patches).
- I have also tried to go back to an older version of logrep: running
with 2 instances with only the first four patches (i.e., leaving out the
support-for-existing-data patch). With only those 4, the logical
replication is solid. (a quick 25x repetition of a (very similar) test
program is 100% successful). So the problem is likely somehow in that
last 5th patch.
- A 25x repetition of a test on a master + replica 5-patch server yields
13 ok, 12 NOK.
- Is the 'make check' FAILED test 'object_addess' unrelated? (Can you
at least reproduce that failed test?)
Maybe add this to the 10 Open Items list? https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items
It may garner a bit more attention.
thanks,
Erik Rijkers