From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
To: Erik Rijkers <er@xs4all.nl>
To: 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, 9 May 2017 10:50:34 +0200
Message-ID: <46835ad4-ce7d-ae45-bfdd-9e5f79d33a89@2ndquadrant.com> (raw)
In-Reply-To: <076a3e4c3d4fef091522d3cd7e50c7eb@xs4all.nl>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
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: petr.jelinek@2ndquadrant.com, er@xs4all.nl, andres@anarazel.de, robertmhaas@gmail.com, craig@2ndquadrant.com
Subject: Re: snapbuild woes
In-Reply-To: <46835ad4-ce7d-ae45-bfdd-9e5f79d33a89@2ndquadrant.com>
* 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