Re: BUG #14999: pg_rewind corrupts control file global/pg_control

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: TipTop Labs <office(at)tiptop-labs(dot)com>,Dmitry Dolgov <9erthalion6(at)gmail(dot)com>,Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>,PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Date: 2018-04-09 04:58:26
Message-ID: 20180409045826.GA1740@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-bugs

On Sun, Apr 08, 2018 at 07:22:58AM +0900, Michael Paquier wrote:
> Yes, that's one of the methods I mentioned in my previous email. Now,
> do we want to fail the run immediately if such a file is found? Or do
> we want to report at once all such files so as the user does not need to
> run multiple times pg_rewind.

So I have been playing with that part...

> The latter would be much more useful.

While that would be nice, the result is rather ugly and this needs to
generate the same error message in two code paths. So I have chewed
things in such a way that one failure found makes the whole rewind to
just fail, and allows retries to work. The attached has a test as well
as documentation.

Thoughts?

> A downside here is that the file from the source would still be fetched
> and copied on the target. So a file which was in read-only would become
> basically writable. Don't think that it is a big deal as the has
> superuser rights at this point, but that's worth mentioning.

That's mentioned in the docs of the attached.
--
Michael

Attachment Content-Type Size
rewind-readonly-v4.patch text/x-diff 5.4 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2018-04-09 04:59:45 Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?
Previous Message Kyotaro HORIGUCHI 2018-04-09 04:26:54 Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?