Re: snapbuild woes

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...