1. Since commit
b1a9bad9e744 we had pstrdup() inside a
spinlock-protected critical section; reported by Andreas Seltenreich.
Turn those into strlcpy() to stack-allocated variables instead.
Backpatch to 9.6.
2. Since commit
9ed551e0a4fd we had a pfree() uselessly inside a
spinlock-protected critical section. Tom Lane noticed in code review.
Move down. Backpatch to 9.6.
3. Since commit
64233902d22b we had GetCurrentTimestamp() (a kernel
call) inside a spinlock-protected critical section. Tom Lane noticed in
code review. Move it up. Backpatch to 9.2.
4. Since commit
1bb2558046cc we did elog(PANIC) while holding spinlock.
Tom Lane noticed in code review. Release spinlock before dying.
Backpatch to 9.2.
Discussion: https://postgr.es/m/
[email protected]
/* use volatile pointer to prevent code rearrangement */
volatile WalRcvData *walrcv = WalRcv;
+ TimestampTz now;
/*
* WalRcv should be set up already (if we are a backend, we inherit this
*/
Assert(walrcv != NULL);
+ now = GetCurrentTimestamp();
+
/*
* Mark walreceiver as running in shared memory.
*
case WALRCV_RUNNING:
/* Shouldn't happen */
+ SpinLockRelease(&walrcv->mutex);
elog(PANIC, "walreceiver still running according to shared memory state");
}
/* Advertise our PID so that the startup process can kill us */
startpoint = walrcv->receiveStart;
/* Initialise to a sanish value */
- walrcv->lastMsgSendTime = walrcv->lastMsgReceiptTime = walrcv->latestWalEndTime = GetCurrentTimestamp();
+ walrcv->lastMsgSendTime =
+ walrcv->lastMsgReceiptTime = walrcv->latestWalEndTime = now;
SpinLockRelease(&walrcv->mutex);