| From: | Nikolay Samokhvalov <nik(at)postgres(dot)ai> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: IO wait events for COPY FROM/TO PROGRAM or file |
| Date: | 2026-02-03 23:42:16 |
| Message-ID: | CAM527d9ro4r8X98_wF-AHRahDJ=jjCRnhEgj-+FXJz0t-j8WXQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Feb 2, 2026 at 7:27 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Sat, Jan 31, 2026 at 11:51:39AM -0800, Nikolay Samokhvalov wrote:
> > v2 attached with the rename per feedback: COPY_DATA_READ/WRITE →
> > COPY_FROM_READ/COPY_TO_WRITE.
> >
> > Given how small this patch is, any chance it could still make PG19?
>
> While double-checking the code, one thing felt incorrect in the
> description of these two new wait events, as copyto.c and
> copyfromparse.c can set copy_file under copy_dest=COPY_FILE for three
> cases, not two contrary to what is said upthread:
> - PROGRESS_COPY_TYPE_FILE
> - PROGRESS_COPY_TYPE_PROGRAM
> - PROGRESS_COPY_TYPE_PIPE, for a non-DestRemote.
>
> The COPY code is designed to be pluggable depending on what extension
> code passes down as option, and not mentioning the pipe case would be
> incorrect. Added a mention about this part, and called it a day.
>
Thank you!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-02-03 23:46:25 | Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible |
| Previous Message | Andres Freund | 2026-02-03 23:16:17 | Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible |