From: Erik Rijkers <er@xs4all.nl>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Craig Ringer <craig@2ndquadrant.com>
Subject: Re: snapbuild woes
Date: Tue, 09 May 2017 10:59:22 +0200
Message-ID: <169b7d221f3236b7cb790c8dd323dbe0@xs4all.nl> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: er@xs4all.nl, petr.jelinek@2ndquadrant.com, andres@anarazel.de, robertmhaas@gmail.com, craig@2ndquadrant.com
Subject: Re: snapbuild woes
In-Reply-To: <169b7d221f3236b7cb790c8dd323dbe0@xs4all.nl>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox