Re: IO wait events for COPY FROM/TO PROGRAM or file

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nikolay Samokhvalov <nik(at)postgres(dot)ai>
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 03:27:49
Message-ID: aYFrNRWAftO3Z5pv@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2026-02-03 03:34:14 Re: Add expressions to pg_restore_extended_stats()
Previous Message Michael Paquier 2026-02-03 02:41:15 Re: Add expressions to pg_restore_extended_stats()