diff options
| author | Michael Paquier <michael@paquier.xyz> | 2018-11-02 07:59:24 +0900 |
|---|---|---|
| committer | Michael Paquier <michael@paquier.xyz> | 2018-11-02 07:59:24 +0900 |
| commit | 6286efb5240f4ce4f1cd51bc11f49d367b7e7f62 (patch) | |
| tree | 82b51c23cb247cb14d48116321c62cf3b537fa98 | |
| parent | 96b00c433cd615144a34ff1a79d691d8b297120d (diff) | |
| download | postgresql-6286efb5240f4ce4f1cd51bc11f49d367b7e7f62.tar.gz postgresql-6286efb5240f4ce4f1cd51bc11f49d367b7e7f62.zip | |
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
| -rw-r--r-- | src/backend/replication/slot.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c index b40268bf124..c3afaf46422 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."))); } |