Re: Refactor pg_rewind code and make it work against a standby

Hello.

At Wed, 19 Aug 2020 15:50:16 +0300, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote in
> Hi,
>
> I started to hack on making pg_rewind crash-safe (see [1]), but I
> quickly got side-tracked into refactoring and tidying up up the code
> in general. I ended up with this series of patches:

^^;

> The first four patches are just refactoring that make the code and the
> logic more readable. Tom Lane commented about the messy comments
> earlier (see [2]), and I hope these patches will alleviate that
> confusion. See commit messages for details.

0001: It looks fine. The new location is reasonable but adding one
extern is a bit annoying. But I don't object it.

0002: Rewording that old->target and new->source makes the meaning far
clearer. Moving decisions core code into filemap_finalize is
reasonable.

By the way, some of the rules are remaining in
process_source/target_file. For example, pg_wal that is a symlink,
or tmporary directories. and excluded files. The number of
excluded files doesn't seem so large so it doesn't seem that the
exclusion give advantage so much. They seem to me movable to
filemap_finalize, and we can get rid of the callbacks by doing
so. Is there any reason that the remaining rules should be in the
callbacks?

0003: Thomas is propsing sort template. It could be used if committed.

0004:

The names of many of the functions gets an additional word "local"
but I don't get the meaning clearly. but its about linguistic sense
and I'm not fit to that..

-rewind_copy_file_range(const char *path, off_t begin, off_t end, bool trunc)
+local_fetch_file_range(rewind_source *source, const char *path, uint64 off,

The function actually copying the soruce range to the target file. So
"fetch" might give somewhat different meaning, but its about
linguistic (omitted..).

> The last patch refactors the logic in libpq_fetch.c, so that it no
> longer uses a temporary table in the source system. That allows using
> a hot standby server as the pg_rewind source.

That sounds nice.

> This doesn't do anything about pg_rewind's crash-safety yet, but I'll
> try work on that after these patches.
>
> [1]
> https://www.postgresql.org/message-id/d8dcc760-8780-5084-f066-6d663801d2e2%40iki.fi
>
> [2]
> https://www.postgresql.org/message-id/30255.1522711675%40sss.pgh.pa.us
>
> - Heikki

I'm going to continue reviewing this later.

reagards.

--
Kyotaro Horiguchi
NTT Open Source Software Center