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 fcab55ec-660a-bc43-7fe1-09af3665e89a@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: buildfarm: could not read block 3 in file "base/16384/2662": readonly 0 of 8192 bytes  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes
Список pgsql-hackers
On 08/11/2018 03:16 PM, Tomas Vondra wrote:
> On 08/11/2018 05:02 AM, Tom Lane wrote:
>> Peter Geoghegan <pg@bowt.ie> writes:
>>> I'm concerned that this item has the potential to delay the release,
>>> since, as you said, we're back to the drawing board.
>>
>> Me too.  I will absolutely not vote to release 11.0 before we've
>> solved this ...
>>
> 
> Not sure. I can easily reproduce that on REL_10_STABLE, so it's not a
> new issue specific to 11.0.
> 

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

I don't think the 20-client COPY concurrency is necessary, it just makes
restarts after the statement_timeout faster.

This produces about the same backtrace as reported on the other thread.
Attaches is both plain 'bt' and 'bt full'.


regards

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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: buildfarm: could not read block 3 in file "base/16384/2662": readonly 0 of 8192 bytes
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: logical decoding / rewrite map vs. maxAllocatedDescs