Re: [HACKERS] Logical replication existing data copy

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