Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes - Mailing list pgsql-hackers

From Andres Freund
Subject Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes
Date
Msg-id 20180811140823.gyxqbtjbr5uitgsf@alap3.anarazel.de
Whole thread Raw
In response to Re: buildfarm: could not read block 3 in file "base/16384/2662": readonly 0 of 8192 bytes  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: buildfarm: could not read block 3 in file "base/16384/2662": readonly 0 of 8192 bytes
Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes
List pgsql-hackers
Hi,

On 2018-08-11 15:40:19 +0200, Tomas Vondra wrote:
> For the record, I can actually reproduce this on 9.6 (haven't tried
> older releases, but I suspect it's there too). Instead of using the
> failing subscription, I've used another pgbench script doing this:

>   SET statement_timeout = 5;
>   COPY t TO '/dev/null';
> 
> and doing something like:
> 
>    pgbench -n -c 20 -T 300 -f copy.sql test

Just to confirm: That's with the vacuum full and insert running
concurrently? And then just restarting the above copy.sql (as pgbench
errors out after the timeouts) until you get the error?

I'm a bit confused what the copy + timeout is doing here? It shouldn't
trigger any invalidations itself, and the backtrace appears to be from
the insert.sql you posted earlier? Unclear why a copy to /dev/null
should trigger anything like this?

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: logical decoding / rewrite map vs. maxAllocatedDescs
Next
From: Tom Lane
Date:
Subject: Re: logical decoding / rewrite map vs. maxAllocatedDescs