Re: buildfarm: could not read block 3 in file "base/16384/2662": readonly 0 of 8192 bytes
От | Tomas Vondra |
---|---|
Тема | Re: buildfarm: could not read block 3 in file "base/16384/2662": readonly 0 of 8192 bytes |
Дата | |
Msg-id | e147d38a-72df-c143-f30f-1f5b71df2a7a@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: