From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes |
Date: | 2018-08-11 14:08:23 |
Message-ID: | 20180811140823.gyxqbtjbr5uitgsf@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-08-11 14:15:56 | Re: logical decoding / rewrite map vs. maxAllocatedDescs |
Previous Message | Tomas Vondra | 2018-08-11 13:43:55 | Re: logical decoding / rewrite map vs. maxAllocatedDescs |