| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_upgrade --copy-file-range |
| Date: | 2024-03-05 23:13:46 |
| Message-ID: | CA+hUKGJX0ooEmDs25H4Y-OzPHhOySPLayALC218sx2G9x+PBYg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 6, 2024 at 2:43 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> As far as I can tell, the original pg_upgrade patch has been ready to
> commit since October. Unless Thomas has any qualms that have not been
> made explicit in this thread, I suggest we move ahead with that.
pg_upgrade --copy-file-range pushed. The only change I made was to
remove the EINTR retry condition which was subtly wrong and actually
not needed here AFAICS. (Erm, maybe I did have an unexpressed qualm
about some bug reports unfolding around that time about corruption
linked to copy_file_range that might have spooked me but those seem to
have been addressed.)
> And then Jakub could rebase his patch set on top of that. It looks like
> if the formatting issues are fixed, the remaining pg_combinebackup
> support isn't that big.
+1
I'll also go and rebase CREATE DATABASE ... STRATEGY=file_clone[1].
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2024-03-05 23:20:13 | Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases |
| Previous Message | Michael Paquier | 2024-03-05 23:11:15 | Re: Remove unnecessary code from psql's watch command |