Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Поиск
Список
Период
Сортировка
От Christoph Berg
Тема Re: A failure in 031_recovery_conflict.pl on Debian/s390x
Дата
Msg-id ZNSqn2g8jUwutufb@msg.df7cb.de
обсуждение исходный текст
Ответ на Re: A failure in 031_recovery_conflict.pl on Debian/s390x  (Christoph Berg <myon@debian.org>)
Ответы Re: A failure in 031_recovery_conflict.pl on Debian/s390x  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
Re: To Thomas Munro
> 603 iterations later it hit again, but didn't log anything. (I believe
> I did run "make" in the right directory.)

This time it took 3086 iterations to hit the problem.

Running c27f8621eedf7 + Debian patches + v8 +
pgstat-report-conflicts-immediately.patch + the XXX logging.

> [22:20:24.714](3.145s) # issuing query via background psql:
> #     BEGIN;
> #     DECLARE test_recovery_conflict_cursor CURSOR FOR SELECT b FROM test_recovery_conflict_table1;
> #     FETCH FORWARD FROM test_recovery_conflict_cursor;
> [22:20:24.745](0.031s) ok 1 - buffer pin conflict: cursor with conflicting pin established
> Waiting for replication conn standby's replay_lsn to pass 0/3430000 on primary
> done
> timed out waiting for match: (?^:User was holding shared buffer pin for too long) at t/031_recovery_conflict.pl line
318.

No XXX lines this time either, but I've seen then im logfiles that
went through successfully.

> Perhaps this can simply be attributed to the machine being too busy.

With the patches, the problem of dying so often that builds targeting
several distributions in parallel will usually fail is gone.

Christoph

Вложения

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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Fix pg_stat_reset_single_table_counters function
Следующее
От: Yuya Watari
Дата:
Сообщение: Re: [PoC] Reducing planning time when tables have many partitions