Re: pg_basebackup, walreceiver and wal_sender_timeout

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

In response to

Responses

Browse pgsql-hackers by date

  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