Re: Two patches to speed up pg_rewind.

From: Paul Guo <guopa(at)vmware(dot)com>
To:
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Two patches to speed up pg_rewind.
Date: 2021-05-28 05:30:51
Message-ID: SA1PR05MB8582BD2ED7AE10ED690BE521C3229@SA1PR05MB8582.namprd05.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On 2021/2/19, 10:33 AM, "Paul Guo" <guopa(at)vmware(dot)com> wrote:

> Refactored the code a bit along with fixes. Manually tested them on centos
> & Ubuntu (the later has copy_file_range())

> For the first patch, actually I have some concerns. My assumption is that
> the target pg_data directory should be fsync-ed already. This should be
> correct normally but there is one scenario: a cleanly-shutdown database’s
> pgdata directory was copied to another directory, in this case the new pgdata
> is not fsync-ed - I’m not sure if that exists in real production environment or not,
> but even considering this we could still use the optimization for the case that
> calls ensureCleanShutdown() since this ensures a pgdata fsync on the target.
Did some small modification and rebased the code. See attached for the new version.

Attachment Content-Type Size
v3-0001-Fsync-the-affected-files-directories-only-in-pg_r.patch application/octet-stream 9.4 KB
v3-0002-Use-copy_file_range-for-file-copying-in-pg_rewind.patch application/octet-stream 5.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-05-28 05:43:44 Re: Parallel Inserts in CREATE TABLE AS
Previous Message tanghy.fnst@fujitsu.com 2021-05-28 05:16:12 [BUG]Update Toast data failure in logical replication