| From: | Paul Guo <guopa(at)vmware(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| 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-02-19 02:33:13 |
| Message-ID: | 25CFBDF2-5551-4CC3-ADEB-434B6B1BAD16@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Fsync-the-affected-files-directories-only-in-pg_r.patch | application/octet-stream | 8.8 KB |
| v2-0002-Use-copy_file_range-for-file-copying-in-pg_rewind.patch | application/octet-stream | 5.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhihong Yu | 2021-02-19 02:33:43 | Re: PoC Refactor AM analyse API |
| Previous Message | Denis Smirnov | 2021-02-19 02:06:12 | Re: PoC Refactor AM analyse API |