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 ZNJKwdzW0QUyd0Vc@msg.df7cb.de
обсуждение исходный текст
Ответ на Re: A failure in 031_recovery_conflict.pl on Debian/s390x  (Andres Freund <andres@anarazel.de>)
Ответы Re: A failure in 031_recovery_conflict.pl on Debian/s390x  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
Re: Andres Freund
> Hm, that could just be a "harmless" race. Does it still happen if you apply
> the attached patch in addition?

Putting that patch on top of v8 made it pass 294 times before exiting
like this:

[08:52:34.134](0.032s) 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.

But admittedly, this build machine is quite sluggish at times, likely
due to neighboring VMs on the same host. (Perhaps that even explains
the behavior from before this patch.) I'll still attach the logs since
I frankly can't judge what errors are acceptable here and which
aren't.

Christoph

Вложения

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

Предыдущее
От: "Jonathan S. Katz"
Дата:
Сообщение: Re: 2023-08-10 release announcement draft
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning