On 18/02/17 14:17, Erik Rijkers wrote:
> 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?)
>
Yes, it has nothing to do with that, that just needs to be updated to
use SKIP CONNECT instead of NOCREATE SLOT in this patch since NOCREATE
SLOT is no longer enough to skip the connection attempt. And I have that
fixed locally, but that does not deserve new patch version given the
main issue you reported.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services