Re: Performance degradation on concurrent COPY into a single relation in PG16.

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