Hi,
On 2023-09-25 15:42:26 -0400, Tom Lane wrote:
> I just did a git bisect run to discover when the failure documented
> in bug #18130 [1] started. And the answer is commit 82a4edabd.
> Now, it's pretty obvious that that commit didn't in itself cause
> problems like this:
>
> postgres=# \copy test from 'bug18130.csv' csv
> ERROR: could not read block 5 in file "base/5/17005": read only 0 of 8192 bytes
> CONTEXT: COPY test, line 472: "0,185647715,222655,489637,2,2023-07-31,9100.0000000,302110385,2023-07-30
14:16:36.750981+00,14026347..."
Ugh.
> IMO there must be some very nasty bug lurking in the new
> multiple-block extension logic, that happens to be exposed by this
> test case with 82a4edabd's adjustments to the when-to-extend choices
> but wasn't before that.
> To save other people the trouble of extracting the in-line data
> in the bug submission, I've attached the test files I was using.
Thanks, looking at this now.
> The DDL is simplified slightly from what was submitted. I'm not
> entirely sure why a no-op trigger is needed to provoke the bug...
A trigger might prevent using the multi-insert API, which would lead to
different execution paths...
Greetings,
Andres Freund