Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit6286efb

Browse files
committed
Lower error level from PANIC to FATAL when restoring slots at startup
When restoring slot information from disk at startup and filling inshared memory information, the startup process would issue a PANICmessage if more slots are found than what max_replication_slots allows,and then Postgres generates a core dump, recommending to increasemax_replication_slots. This gives users a switch to crash Postgres atwill by creating slots, lower the configuration to not support it, andthen restart it.Making Postgres crash hard in this case is overdoing it just to give arecommendation to users. So instead use a FATAL, which makes Postgresfail to start without crashing, still giving the recommendation. Thisis more consistent with what happens for prepared transactions forexample.Author: Michael PaquierReviewed-by: Andres FreundDiscussion:https://postgr.es/m/20181030025109.GD1644@paquier.xyz
1 parent96b00c4 commit6286efb

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

‎src/backend/replication/slot.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1563,7 +1563,7 @@ RestoreSlotFromDisk(const char *name)
15631563
}
15641564

15651565
if (!restored)
1566-
ereport(PANIC,
1566+
ereport(FATAL,
15671567
(errmsg("too many replication slots active before shutdown"),
15681568
errhint("Increase max_replication_slots and try again.")));
15691569
}

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp