On Tue, Sep 08, 2026 at 01:11:00PM +0300, Nazir Bilal Yavuz wrote: > Here is an attempt to solve this problem. I ran Manni's script and saw > a 1-2% slowdown on TEXT-wide inputs. It is still faster compared to > the version without the SIMD patch; the slowdown is relative to the > current master branch (which includes the SIMD patch).
Thanks for reporting. Fable 5.1 suggests moving the check to CopyLoadInputBuf() to avoid this small regression, which makes sense to me. I've attached a new patch that does that. This is definitely a bit of hack, and I'm assuming we'll need to revisit this if we want to re-attempt more sophisticated heuristics for when to use the SIMD path. But IMHO this is self-contained enough to be reasonable for v19. -- nathan
>From 2323f8bbc97467238859ece05f3b6da5524c7593 Mon Sep 17 00:00:00 2001 From: Nathan Bossart <[email protected]> Date: Tue, 8 Sep 2026 10:24:31 -0500 Subject: [PATCH v2 1/1] Fix hangs in COPY FROM (FORMAT text). The SIMD path for this command reads ahead via CopyLoadInputBuf() whenever fewer than sizeof(Vector8) bytes remain in the input buffer, even if those bytes hold a complete end-of-copy marker. If the input is a pipe whose writer has sent the marker but not closed the pipe, that read blocks, and COPY waits for data it will never use. The scalar loop asks only for the bytes it needs, so it stops at the marker without reading any further. To fix, teach CopyLoadInputBuf() to decline a speculative load when the caller's remaining bytes contain a backslash, which in text mode might begin such a marker. (CSV mode doesn't treat \. as special, so it is unaffected.) The SIMD path then hands those bytes to the scalar loop, as it already does when a load comes up short. Checking for the marker in the SIMD helper itself would be more direct, but a call there costs the compiler registers on every line, which measurably slowed COPY of short lines in my testing. Oversight in commit e0a3a3fd53. Author: Nazir Bilal Yavuz <[email protected]> Discussion: https://postgr.es/m/CAN55FZ1qFb4Yo3-MWeQfGQnu1_Ksx4xcFC2m3hyw8a--%2BeHQYQ%40mail.gmail.com Backpatch-through: 19 --- src/backend/commands/copyfromparse.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/src/backend/commands/copyfromparse.c b/src/backend/commands/copyfromparse.c index 98bf30ef2e7..68088108c7c 100644 --- a/src/backend/commands/copyfromparse.c +++ b/src/backend/commands/copyfromparse.c @@ -652,16 +652,30 @@ CopyLoadRawBuf(CopyFromState cstate) * If INPUT_BUF_BYTES(cstate) > 0, the unprocessed bytes are moved to the start * of the buffer and then we load more data after that. * - * If "speculative" is true, this function skips reporting any encoding or - * conversion errors, provided there are still data for the caller to process. - * Such callers must be prepared for this function to return without loading - * anything. + * If "speculative" is true, the caller has not yet examined the data left in + * input_buf and needn't load more to make progress. In that case, this + * function skips reporting any encoding or conversion errors, and in text + * mode it declines to read past a backslash, as that might begin an + * end-of-copy marker. Such callers must be prepared for this function to + * return without loading anything. */ static void CopyLoadInputBuf(CopyFromState cstate, bool speculative) { int nbytes = INPUT_BUF_BYTES(cstate); + /* + * In text mode, a backslash among the bytes a speculative caller has yet + * to examine might begin an end-of-copy marker. The caller must find + * that on its own, without waiting on input that may never arrive, as + * from a pipe whose writer has sent the marker but not closed the pipe. + * So in that case, just return without loading anything. + */ + if (speculative && cstate->opts.format == COPY_FORMAT_TEXT && + memchr(cstate->input_buf + cstate->input_buf_index, '\\', + nbytes) != NULL) + return; + /* * The caller has updated input_buf_index to indicate how much of the * input has been consumed and isn't needed anymore. If input_buf is the -- 2.55.0
