Re: A failure in 031_recovery_conflict.pl on Debian/s390x - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: A failure in 031_recovery_conflict.pl on Debian/s390x
Date
Msg-id ZNSqn2g8jUwutufb@msg.df7cb.de
Whole thread Raw
In response to Re: A failure in 031_recovery_conflict.pl on Debian/s390x  (Christoph Berg <myon@debian.org>)
Responses Re: A failure in 031_recovery_conflict.pl on Debian/s390x
List 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

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Fix pg_stat_reset_single_table_counters function
Next
From: Yuya Watari
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions