Re: Refactor pg_rewind code and make it work against a standby
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: hlinnaka@iki.fi
Cc: pgsql-hackers@postgresql.org
Date: 2020-08-20T08:32:24Z
Lists: pgsql-hackers
Hello.
At Wed, 19 Aug 2020 15:50:16 +0300, Heikki Linnakangas <hlinnaka@iki.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
Commits
-
Make pg_rewind test case more stable.
- c71f9a094b32 14.0 landed
-
Fix timing issue in pg_rewind test.
- 39f9f04b5784 14.0 landed
-
Allow pg_rewind to use a standby server as the source system.
- 9c4f5192f69e 14.0 landed
-
pg_rewind: Refactor the abstraction to fetch from local/libpq source.
- 37d2ff380312 14.0 landed
-
pg_rewind: Replace the hybrid list+array data structure with simplehash.
- f81e97d0475c 14.0 landed
-
Refactor pg_rewind for more clear decision making.
- eb00f1d4bf96 14.0 landed
-
pg_rewind: Move syncTargetDirectory() to file_ops.c
- ffb4e27e9c5e 14.0 landed