Re: pg_rewind just doesn't fsync *anything*?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: pg_rewind just doesn't fsync *anything*?
Date: 2016-03-10 18:52:16
Message-ID: 20160310185216.7lwjlk2forylemgs@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2016-03-10 08:47:16 +0100, Michael Paquier wrote:
> Still, I think that we had better fsync only entries that are modified
> by pg_rewind, and files that got updated, and not the whole directory

Why? If any files in there are dirty, they need to be fsynced. If
they're not dirty, fsync's free.

> a target data folder should be stopped properly to be able to rewind,
> and it is better to avoid dependencies between utilities if that's not
> strictly necessary. initdb is likely to be installed side-by-side
> with pg_rewind in any distribution though.

It's not like we don't have any other such dependencies, in other
binaries. I'm not concerned.

Having to backpatch a single system() invocation + find_other_exec()
call, and backporting a more general FRONTEND version of initdb's
fsync_pgdata() are wildly differing in complexity.

- Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-03-10 18:55:47 pgsql: Provide much better wait information in pg_stat_activity.
Previous Message Tom Lane 2016-03-10 18:48:31 Re: WIP: Upper planner pathification