Re: pg_basebackup, walreceiver and wal_sender_timeout - Mailing list pgsql-hackers

From Nick B
Subject Re: pg_basebackup, walreceiver and wal_sender_timeout
Date
Msg-id CAPHA_mkbfEuxHPbmzDSQx4j=5VHPZYk-ffFxg=xi5_M2fxnHDw@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup, walreceiver and wal_sender_timeout  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_basebackup, walreceiver and wal_sender_timeout  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Sat, Jan 26, 2019 at 4:23 AM Michael Paquier <michael@paquier.xyz> wrote:
> These are a bit unregular.  Which files are taking that long to
> complete while others are way faster?  It may be something that we
> could improve on the base backup side as there is no actual point in
> syncing segments while the backup is running and we could delay that
> at the end of the backup (if I recall that stuff correctly).

I don't have a good sample for these. One instance of this happening is below:
....
0.000125 fsync(7)                  = 0 <0.016677>
0.000039 fsync(7)                  = 0 <0.000005>
# 2048 writes for total of 16777216 bytes (16MB)
0.000618 write(7,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
8192) = 8192 <0.000021>
0.000078 fsync(8)                  = 0 <57.609720>
57.609830 fsync(8)                  = 0 <0.000007>

Again, it is a problem with our network file system that we are still
investigating. I'm not sure this can be improved easily, since
pg_basebackup shares this code with walreceiver.

> The docs could be improved to describe that better..

I will look into that.

Regards,
Nick.


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [PATCH] Allow UNLISTEN during recovery
Next
From: Magnus Hagander
Date:
Subject: Re: pg_basebackup, walreceiver and wal_sender_timeout