MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 09 May 2017 10:59:22 +0200
From: Erik Rijkers <er@xs4all.nl>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL-development
 <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, Craig
 Ringer <craig@2ndquadrant.com>
Subject: Re: snapbuild woes
In-Reply-To: <46835ad4-ce7d-ae45-bfdd-9e5f79d33a89@2ndquadrant.com>
References: <20170413002959.apytyi5lkknauauj@alap3.anarazel.de>
 <0d06dfc1-0bc5-c3ab-3555-24e2f275d7fa@2ndquadrant.com>
 <30242bc6-eca4-b7bb-670e-8d0458753a8c@2ndquadrant.com>
 <20170501005921.qcqd7w2njpv3av6s@alap3.anarazel.de>
 <20170501013529.sejtgo2acxbvq26q@alap3.anarazel.de>
 <209861fc-718f-0a7b-3a1d-36512865c209@2ndquadrant.com>
 <20170501080348.vb6mj5whdex3f7l7@alap3.anarazel.de>
 <e6c1fdfe-50bc-62e4-3ad7-854f6ac5c35e@2ndquadrant.com>
 <20170501191419.coqbtx2jodu22ufz@alap3.anarazel.de>
 <ba7a3052-6e71-d162-d4a0-b5bdd7145c19@2ndquadrant.com>
 <20170505000004.gihrtl7bhxeolf3q@alap3.anarazel.de>
 <076a3e4c3d4fef091522d3cd7e50c7eb@xs4all.nl>
 <46835ad4-ce7d-ae45-bfdd-9e5f79d33a89@2ndquadrant.com>
Message-ID: <169b7d221f3236b7cb790c8dd323dbe0@xs4all.nl>
User-Agent: XS4ALL Webmail
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 2017-05-09 10:50, Petr Jelinek wrote:
> On 09/05/17 00:03, Erik Rijkers wrote:
>> On 2017-05-05 02:00, Andres Freund wrote:
>>> 
>>> Could you have a look?
>> 
>> Running tests with these three patches:
>> 
>>> 0001-WIP-Fix-off-by-one-around-GetLastImportantRecPtr.patch+
>>> 0002-WIP-Possibly-more-robust-snapbuild-approach.patch     +
>>> fix-statistics-reporting-in-logical-replication-work.patch
>>     (on top of 44c528810)
>> 
>> I test by 15-minute pgbench runs while there is a logical replication
>> connection. Primary and replica are on the same machine.
>> 
>> I have seen errors on 3 different machines (where error means: at 
>> least
>> 1 of the 4 pgbench tables is not md5-equal). It seems better, faster
>> machines yield less errors.
>> 
>> Normally I see in pg_stat_replication (on master) one process in state
>> 'streaming'.
>> 
>>  pid  |     wal     | replay_loc  |   diff   |   state   |   app   |
>> sync_state
>> 16495 | 11/EDBC0000 | 11/EA3FEEE8 | 58462488 | streaming | derail2 | 
>> async
>> 
>> Often there are another two processes in pg_stat_replication that 
>> remain
>> in state 'startup'.
>> 
>> In the failing sessions the 'streaming'-state process is missing; in
>> failing sessions there are only the two processes that are and remain 
>> in
>> 'startup'.
> 
> Hmm, startup is the state where slot creation is happening. I wonder if
> it's just taking long time to create snapshot because of the 5th issue
> which is not yet fixed (and the original patch will not apply on top of
> this change). Alternatively there is a bug in this patch.
> 
> Did you see high CPU usage during the test when there were those
> "startup" state walsenders?
> 

I haven't noticed but I didn't pay attention to that particularly.

I'll try to get some CPU-info logged...


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers