Re: replication_slots usability issue
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, "Joshua D. Drake" <jd@commandprompt.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-10-31T02:10:23Z
Lists: pgsql-hackers
Attachments
- slot-restore-fatal.patch (text/x-diff) patch
On Tue, Oct 30, 2018 at 10:52:54AM -0700, Andres Freund wrote: > On 2018-10-30 11:51:09 +0900, Michael Paquier wrote: >> Er... At the same time, shouldn't RestoreSlotFromDisk() *not* use PANIC >> if more slots are found in pg_replslot than max_replication_slots can >> handle. A FATAL is fine at startup, PANIC blows up a core file, which >> is clearly overdoing it if the goal is to give a recommendation at the >> end. > > I can't get particularly excited about this. This gets only used by the startup process to restore slot information, so for example if you have an instance with two slots, shut it down, reduce max_replication_slots to 1, and restart then you generate a core dump, which is a bit overdoing it to simply let the user know that he just needs to bump up one parameter and to give him a recommendation to do so :) For example: 2018-10-31 11:04:08 JST [9014]: [11-1] db=,user=,app=,client= DEBUG: starting up replication slots 2018-10-31 11:04:08 JST [9014]: [12-1] db=,user=,app=,client= DEBUG: restoring replication slot from "pg_replslot/popo3/state" 2018-10-31 11:04:08 JST [9014]: [13-1] db=,user=,app=,client= DEBUG: restoring replication slot from "pg_replslot/popo2/state" 2018-10-31 11:04:08 JST [9014]: [14-1] db=,user=,app=,client= PANIC: too many replication slots active before shutdown 2018-10-31 11:04:08 JST [9014]: [15-1] db=,user=,app=,client= HINT: Increase max_replication_slots and try again. > I guess we can change it, but I'd only do so in master. I won't fight hard for a back-patch, now I think that we should back-patch a fix. Generating a core file if a state is unexpected is fine because you expect the system to react so, being able to trigger one based on a parameter switch just to give a recommendation is not in my opinion. For example with the attached the system reacts as follows: 2018-10-31 11:07:23 JST [10063]: [14-1] db=,user=,app=,client= FATAL: too many replication slots active before shutdown 2018-10-31 11:07:23 JST [10063]: [15-1] db=,user=,app=,client= HINT: Increase max_replication_slots and try again. 2018-10-31 11:07:23 JST [10061]: [6-1] db=,user=,app=,client= LOG: startup process (PID 10063) exited with exit code 1 2018-10-31 11:07:23 JST [10061]: [7-1] db=,user=,app=,client= LOG: aborting startup due to startup process failure -- Michael
Commits
-
Fix copy-paste error in errhint() introduced in 691d79a07933.
- b7301e3a7b63 9.4.20 landed
- a0e450e91ee9 9.5.15 landed
- ac36e6aee808 10.6 landed
- a16e8b440132 9.6.11 landed
- 9c7049ef4f9c 11.1 landed
- a3fb382e9c16 12.0 landed
-
Lower error level from PANIC to FATAL when restoring slots at startup
- 6286efb5240f 12.0 landed
-
Fix error message typo introduced 691d79a07933.
- b0fa768c61b3 9.4.20 landed
- 87f76f1324b2 9.6.11 landed
- 877b00561eea 10.6 landed
- 0446551fc114 11.1 landed
- 8a99f8a82775 12.0 landed
- d554e333e548 9.5.15 landed
-
Disallow starting server with insufficient wal_level for existing slot.
- d35fd17cb58d 9.6.11 landed
- cf358a2c066c 9.4.20 landed
- c33a01c7979d 11.1 landed
- 679cb44e4b56 9.5.15 landed
- 021e1c329d7c 10.6 landed
- 691d79a07933 12.0 landed
-
Allow replication slots to be dropped in single-user mode
- a1f680d962ff 10.5 cited