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 |
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 |