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