Re: Refactor pg_rewind code and make it work against a standby - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Refactor pg_rewind code and make it work against a standby
Date
Msg-id 20200820.173224.2258034742176021277.horikyota.ntt@gmail.com
Whole thread Raw
In response to Refactor pg_rewind code and make it work against a standby  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Refactor pg_rewind code and make it work against a standby
List 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



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: "ccold" left by reindex concurrently are droppable?
Next
From: Amit Kapila
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions