From: | Nick B <nbedxp(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_basebackup, walreceiver and wal_sender_timeout |
Date: | 2019-01-26 12:34:49 |
Message-ID: | CAPHA_mkbfEuxHPbmzDSQx4j=5VHPZYk-ffFxg=xi5_M2fxnHDw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 26, 2019 at 4:23 AM Michael Paquier <michael(at)paquier(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2019-01-26 12:45:46 | Re: pg_basebackup, walreceiver and wal_sender_timeout |
Previous Message | Simon Riggs | 2019-01-26 11:09:41 | Re: [PATCH] Allow UNLISTEN during recovery |