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
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 |