From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Chris Travers <chris(dot)travers(at)adjust(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] WIP: Restricting pg_rewind to data/wal dirs |
Date: | 2018-02-01 06:41:25 |
Message-ID: | 20180201064125.GF6398@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 22, 2018 at 03:12:58PM -0500, Stephen Frost wrote:
> I would think the next step here, as Michael suggested very early on in
> this thread, would be to bring the exclude list and perhaps logic for
> pg_basebackup into the common code and have pg_rewind leverage that
> instead of having its own code that largely does the same and then
> adding an option to exclude additional items to that. There's no sense
> having pg_rewind operate on files that are going to end up getting wiped
> out when recovery starts anyway. Perhaps there's a use-case for
> overriding the exclude list with a 'include' option too, but I'm not
> convinced there is.
Me neither. I'll look into getting something for the next commit fest.
There have been way too many complaints about how pg_rewind copies too
much data for nothing to ignore doing something (the last one about
pg_replslot data). A good first step would be what you are writing in
the paragraph above, so I intend to do that as I am sure that it would
be a good addition. For now I have marked the proposed patches as
returned with feedback.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-02-01 06:47:00 | Re: [HACKERS] taking stdbool.h into use |
Previous Message | Michael Paquier | 2018-02-01 06:32:12 | Re: [HACKERS] Cache lookup errors with functions manipulation object addresses |