| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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 19:31:55 |
| Message-ID: | CAB7nPqTqqCHKkFNJc77B_4VcXWJGO8OFgxN+PMa+5pv=eCkMMw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 10, 2016 at 7:52 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> 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.
Talking about HEAD, wouldn't the dependency tree be cleaner if there
is a common facility in src/common? For back-branches, I won't argue
against simplicity, those are more reliable solutions.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2016-03-10 19:34:19 | Re: Using quicksort for every external sort run |
| Previous Message | Robert Haas | 2016-03-10 19:27:55 | Re: Freeze avoidance of very large table. |