| 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: | Whole Thread | Raw Message | 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 |