I recently discovered two possible bugs about synchronous replication.
1. SyncRepCleanupAtProcExit may delete an element that has been deleted SyncRepCleanupAtProcExit first checks whether the queue is detached, if it is not detached, acquires the SyncRepLock lock and deletes it. If this element has been deleted by walsender, it will be deleted repeatedly, SHMQueueDelete will core with a segment fault.
IMO, like SyncRepCancelWait, we should lock the SyncRepLock first and then check whether the queue is detached or not.
I think you're right here.
Indeed. Looking at the surroundings we expect some code paths to hold SyncRepLock in exclusive or shared mode but we don't actually check that the lock is hold. So let's add some assertions while on it.
This is not right. It is in transaction commit so it is in a HOLD_INTERRUPTS section. ProcessInterrupt does not respond to cancel/die interrupts thus the ereport should return.
Yeah. There is an easy way to check after that: InterruptHoldoffCount needs to be strictly positive.
