<div dir="ltr"><div><div>Could Pacemaker’s controller block on a stalled block-device read while faulting in a swapped-<br>out libqb SHM page, before it receives the executor reply and starts the operation timer? </div><div><br></div><div>Would that behavior be expected? </div><div><br></div><div>I'm investigating a lockup where the PostgreSQL primary and Pacemaker DC were on the same node when a degraded RAID array caused reads to appear unbounded without returning errors. Pacemaker did not stop the PostgreSQL resource or promote a standby. crm_mon showed the DC as standby (with active resources).</div><div><br></div><div>Testing that simulates the incident reproduces that production Pacemaker behavior. In that setup a libqb SHM page is swapped out and controller blocks in shmem_fault() before the executor reply and operation timer. The surviving production logs (such as the crm_mon output) match. Corosync membership remained intact in both the incident and the test.</div><div><br></div><font color="#888888"></font><div><font color="#888888"><br></font></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Brian Cosgrove</div></div>