| From: | Christoph Berg <myon(at)debian(dot)org> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: A failure in 031_recovery_conflict.pl on Debian/s390x |
| Date: | 2023-08-08 14:01:37 |
| Message-ID: | ZNJKwdzW0QUyd0Vc@msg.df7cb.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| Attachment | Content-Type | Size |
|---|---|---|
| 031_recovery_conflict_primary.log | text/plain | 6.9 KB |
| 031_recovery_conflict_standby.log | text/plain | 2.4 KB |
| regress_log_031_recovery_conflict | text/plain | 5.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2023-08-08 14:14:50 | Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning |
| Previous Message | Jonathan S. Katz | 2023-08-08 13:39:42 | Re: 2023-08-10 release announcement draft |