Re: Fix stale column context after COPY FROM conversion errors

At 2026-11-05 16:04:17, "Michael Paquier" <michael(at)paquier(dot)xyz> wrote:
>I've also wondered exactly about that a couple of hours ago while
>looking at a different bug in the same area of the code.. Interesting
>timing.
>
>I don't buy that the current coding on HEAD is correct, based on what
>I can see here from this test:
>* SQL input:
>CREATE TABLE check_ign_err (n int, m int[], k int);
>COPY check_ign_err FROM STDIN WITH (on_error ignore);
>bad {1} 3
>1 {1} 3 abc
>\.
>
>* HEAD:
>ERROR: 22P04: extra data after last expected column
>CONTEXT: COPY check_ign_err, line 2, column n: "1"
>* with your patch:
>ERROR: 22P04: extra data after last expected column
>CONTEXT: COPY check_ign_err, line 2: "1 {1} 3 4"
>
>Complaining about the first column on the second line is incorrect and
>gets fed from the first incorrect line: we have extra fields on this
>line, they should be mentioned.
>--

>Michael

Hi,
Indeed, as you mentioned, the error on the second line points to some abnormal data in the first column.
That said, we should also consider the following:
When the COPY rows used in current tests are small enough, the attribute_buf has sufficient capacity.
Since resetStringInfo reuses the same memory block, the leftover cur_attval remains readable.
This only results in garbled error messages.
If we construct two extremely large COPY rows that both trigger repalloc,
the old address will be munmapped while processing the second row.
When the error callback invokes strlen(cur_attval), it accesses unmapped memory,
which causes a deterministic SIGSEGV.
I have reproduced this issue in my local environment.
Therefore, I believe this bug deserves higher priority for fixing.
Chao Li's v1 patch already resolves this problem, LGTM.

Best regards,
Yilin Zhang