diff options
| author | Andres Freund <andres@anarazel.de> | 2022-05-02 18:25:00 -0700 |
|---|---|---|
| committer | Andres Freund <andres@anarazel.de> | 2022-05-02 18:29:52 -0700 |
| commit | edfc03ec91f2ec2574e6aa7d22d3a198c3490ee5 (patch) | |
| tree | e73f398a5dade816839cd5d9925c5a50e3230262 /src/backend/commands/cluster.c | |
| parent | 5c8b14a71d318a15c4db4fd3eb209d5c24934a43 (diff) | |
| download | postgresql-edfc03ec91f2ec2574e6aa7d22d3a198c3490ee5.tar.gz postgresql-edfc03ec91f2ec2574e6aa7d22d3a198c3490ee5.zip | |
Fix possibility of self-deadlock in ResolveRecoveryConflictWithBufferPin().
The tests added in 9f8a050f68d failed nearly reliably on FreeBSD in CI, and
occasionally on the buildfarm. That turns out to be caused not by a bug in the
test, but by a longstanding bug in recovery conflict handling.
The standby timeout handler, used by ResolveRecoveryConflictWithBufferPin(),
executed SendRecoveryConflictWithBufferPin() inside a signal handler. A bad
idea, because the deadlock timeout handler (or a spurious latch set) could
have interrupted ProcWaitForSignal(). If unlucky that could cause a
self-deadlock on ProcArrayLock, if the deadlock check is in
SendRecoveryConflictWithBufferPin()->CancelDBBackends().
To fix, set a flag in StandbyTimeoutHandler(), and check the flag in
ResolveRecoveryConflictWithBufferPin().
Subsequently the recovery conflict tests will be backpatched.
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de
Backpatch: 10-
Diffstat (limited to 'src/backend/commands/cluster.c')
0 files changed, 0 insertions, 0 deletions