pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
Date: Sat, 11 Aug 2018 16:17:48 +0200
Message-ID: <e147d38a-72df-c143-f30f-1f5b71df2a7a@2ndquadrant.com> (raw)
In-Reply-To: <20180811140823.gyxqbtjbr5uitgsf@alap3.anarazel.de>
References: <20180720202450.zcakbvyqksschz5e@alap3.anarazel.de>
	<20180725230736.nscpb5ad2tl64nez@alap3.anarazel.de>
	<CAH2-WzmfC3WuVKCvBtS1agKs5kRu8uKnp_+VReYgD8D1XD0v5A@mail.gmail.com>
	<27669.1533782451@sss.pgh.pa.us>
	<CAH2-WznAuzsQHAObT5+neO50=_PSJYhU_npp65MHaYjdKuM=ng@mail.gmail.com>
	<465.1533955530@sss.pgh.pa.us>
	<CAH2-Wzk_DWsf1bB8NwoKhOM13wkp0Ycjzbg0zfmrr8TGKn1FjA@mail.gmail.com>
	<1368.1533956577@sss.pgh.pa.us>
	<2e674bd6-3bc2-9d70-7d03-db48f7ea5877@2ndquadrant.com>
	<fcab55ec-660a-bc43-7fe1-09af3665e89a@2ndquadrant.com>
	<20180811140823.gyxqbtjbr5uitgsf@alap3.anarazel.de>

On 08/11/2018 04:08 PM, Andres Freund wrote:
> 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?
> 

Yes, pretty much.

> 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?
> 

My goal was to simulate the failing subscription sync, which does COPY
and fails because of duplicate data. The statement_timeout seemed like a
good approximation of that. It may be unnecessary, I don't know.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




view thread (46+ messages)  latest in thread

Message-ID: <e147d38a-72df-c143-f30f-1f5b71df2a7a@2ndquadrant.com>
Permalink:  ../e147d38a-72df-c143-f30f-1f5b71df2a7a@2ndquadrant.com/
Also on:    postgresql.org/message-id/e147d38a-72df-c143-f30f-1f5b71df2a7a@2ndquadrant.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@2ndquadrant.com, andres@anarazel.de, tgl@sss.pgh.pa.us, pg@bowt.ie, pgsql-hackers@lists.postgresql.org
  Subject: Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
  In-Reply-To: <e147d38a-72df-c143-f30f-1f5b71df2a7a@2ndquadrant.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox