From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: file cloning in pg_upgrade and CREATE DATABASE |
Date: | 2018-03-20 02:58:49 |
Message-ID: | 20180320025849.GB4963@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 19, 2018 at 04:14:15PM +0900, Michael Paquier wrote:
> Two other things I have noticed as well:
> 1) src/bin/pg_rewind/copy_fetch.c could benefit from similar speed-ups I
> think when copying data from source to target using the local mode of
> pg_rewind. This could really improve cases where new relations are
> added after a promotion.
> 2) XLogFileCopy() uses a copy logic as well. For large segments things
> could be improved, however we need to be careful about filling in the
> end of segments with zeros.
I have been thinking about this patch over the night, and here is a list
of bullet points which would be nice to tackle:
- Remove the current diff in copydir.
- Extend copy_file so as it is able to use fcopyfile.
- Move the work done in pg_upgrade into a common API which can as well
be used by pg_rewind as well. One place would be to have a
frontend-only API in src/common which does the leg work. I would
recommend working only on file descriptors as well for consistency with
copy_file_range.
- Add proper wait events for the backend calls. Those are missing for
copy_file_range and copyfile.
- For XLogFileCopy, the problem may be trickier as the tail of a segment
is filled with zeroes, so dropping it from the first version of the
patch sounds wiser.
Patch is switched as waiting on author, I have set myself as a
reviewer.
Thanks,
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-03-20 03:07:13 | Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs |
Previous Message | Chapman Flack | 2018-03-20 02:54:59 | Re: configure's checks for --enable-tap-tests are insufficient |