postgrespro.git / summary / log / commit / refs

commit    6286efb5240f4ce4f1cd51bc11f49d367b7e7f62
Author:   Michael Paquier <michael@paquier.xyz>
Date:     Thu Nov 01 22:59:24 2018 +0000

    Lower error level from PANIC to FATAL when restoring slots at startup
    
    When restoring slot information from disk at startup and filling in
    shared memory information, the startup process would issue a PANIC
    message if more slots are found than what max_replication_slots allows,
    and then Postgres generates a core dump, recommending to increase
    max_replication_slots.  This gives users a switch to crash Postgres at
    will by creating slots, lower the configuration to not support it, and
    then restart it.
    
    Making Postgres crash hard in this case is overdoing it just to give a
    recommendation to users.  So instead use a FATAL, which makes Postgres
    fail to start without crashing, still giving the recommendation.  This
    is more consistent with what happens for prepared transactions for
    example.
    
    Author: Michael Paquier
    Reviewed-by: Andres Freund
    Discussion: https://postgr.es/m/20181030025109.GD1644@paquier.xyz


 src/backend/replication/slot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index b40268bf12..c3afaf4642 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1563,7 +1563,7 @@ RestoreSlotFromDisk(const char *name)
 	}
 
 	if (!restored)
-		ereport(PANIC,
+		ereport(FATAL,
 				(errmsg("too many replication slots active before shutdown"),
 				 errhint("Increase max_replication_slots and try again.")));
 }


[parent: 96b00c433cd6]