|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|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|