From: | Alex Kliukin <alexk(at)hintbits(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Nick B <nbedxp(at)gmail(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_basebackup, walreceiver and wal_sender_timeout |
Date: | 2019-01-28 13:00:59 |
Message-ID: | 1548680459.405146.1645180448.5B9D037E@webmail.messagingengine.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 28, 2019, at 10:25, Michael Paquier wrote:
> On Mon, Jan 28, 2019 at 09:05:26AM +0100, Magnus Hagander wrote:
> > And for plain format, we'd do the same -- sync after each file segment, and
> > then a final one of the directory when done, right?
>
> Well, the code is doing a double amount of work in its current shape
> as we call fsync_pgdata() for the plain format, which cascades to
> pg_wal and all its files, so it seems to me that there is little point
> in issuing a sync when each segment is finished streaming if that's
> what you mean.
Agreed.
While reading the doc page for the pg_basebackup, I've been confused by the fact that it says WAL files will be written to .tarballs (either base.tar or pg_wal.tar) when pg_basebackup is instructed to stream WALs alongside the backup itself. I think it makes sense to elaborate that it only happens when tar format is specified (doc patch is attached).
Cheers,
Oleksii
Attachment | Content-Type | Size |
---|---|---|
pg_basebackup_wal_method_clarification_v1.patch | text/plain | 1.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2019-01-28 13:09:42 | Re: WIP: Avoid creation of the free space map for small tables |
Previous Message | Laurenz Albe | 2019-01-28 11:59:30 | Re: "SELECT ... FROM DUAL" is not quite as silly as it appears |