Re: Simplify final sync in pg_rewind's target folder and add --no-sync

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Simplify final sync in pg_rewind's target folder and add --no-sync
Date: 2018-07-09 13:38:11
Message-ID: 3640d916-bfed-fc71-b54a-e1507813890e@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 25/03/18 15:26, Michael Paquier wrote:
> Hi all,
>
> While looking at pg_rewind code, I have been surprised to find that the
> final fsync done on the target's data folder is done using initdb -S via
> a system() call. This is in my opinion overcomplicated because we have
> a dedicated API in fe_utils able to do a fsync on a data folder, called
> fsync_pgdata() that I have implemented when working on data durability
> for the other backup tools. So I would like to simplify the code as
> attached.
>
> One difference that this patch introduces is that a failed sync is not
> considered as a failure, still failures are reported to stderr. This
> new behavior is actually more consistent with what happens in pg_dump
> and pg_basebackup. And we have decided previously to do so, see here
> for more details on the discussion:
> https://www.postgresql.org/message-id/CAB7nPqQ_B0j3n1t%3D8c1ZLHXF1b8Tf4XsXoUC9bP9t5Hab--SMg%40mail.gmail.com
>
> An extra thing I have noticed, which is I think an oversight, is that
> there is no --no-sync option in pg_rewind. Like the other binaries,
> this is useful to reduce the I/O effort when running tests.

Yeah, let's be consistent with the other utilities, on both of those things.

> Both things are implemented as attached. I am of course not pushing for
> integrating that patch in v11 even if it is straight-forward, so I'll
> park it in the next future commit fest.

Looks good to me. I'll mark this as "ready for committer".

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2018-07-09 13:49:36 Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
Previous Message Jesper Pedersen 2018-07-09 13:30:43 Re: EXPLAIN of Parallel Append