Fix oversight from 9e149c8 with spin-lock handling
authorMichael Paquier <michael@paquier.xyz>
Mon, 11 Jun 2018 21:52:34 +0000 (06:52 +0900)
committerMichael Paquier <michael@paquier.xyz>
Mon, 11 Jun 2018 21:52:34 +0000 (06:52 +0900)
Calling an external function while a pin-lock is held is a bad idea as
those are designed to be short-lived.  The stress of a first commit into
a large git history may contribute to that.

Reported-by: Andres Freund
Discussion: https://postgr.es/m/20180611164952.vmxdpdpirdtkdsz6@alap3.anarazel.de

src/backend/replication/slot.c

index 79d7a57d677fba75aba913688659148215c44dee..e8b76b2f207c1bb7abb22eea028c1a740a85d9e7 100644 (file)
@@ -999,6 +999,7 @@ ReplicationSlotReserveWal(void)
    while (true)
    {
        XLogSegNo   segno;
+       XLogRecPtr  restart_lsn;
 
        /*
         * For logical slots log a standby snapshot and start logical decoding
@@ -1016,8 +1017,9 @@ ReplicationSlotReserveWal(void)
            XLogRecPtr  flushptr;
 
            /* start at current insert position */
+           restart_lsn = GetXLogInsertRecPtr();
            SpinLockAcquire(&slot->mutex);
-           slot->data.restart_lsn = GetXLogInsertRecPtr();
+           slot->data.restart_lsn = restart_lsn;
            SpinLockRelease(&slot->mutex);
 
            /* make sure we have enough information to start */
@@ -1028,8 +1030,9 @@ ReplicationSlotReserveWal(void)
        }
        else
        {
+           restart_lsn = GetRedoRecPtr();
            SpinLockAcquire(&slot->mutex);
-           slot->data.restart_lsn = GetRedoRecPtr();
+           slot->data.restart_lsn = restart_lsn;
            SpinLockRelease(&slot->mutex);
        }