From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: replication_slots usability issue |
Date: | 2018-10-30 02:51:09 |
Message-ID: | 20181030025109.GD1644@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 29, 2018 at 12:13:04PM -0700, Andres Freund wrote:
> I don't think this quite is the problem. ISTM the issue is rather that
> StartupReplicationSlots() *needs* to check whether wal_level > minimal,
> and doesn't. So you can create a slot, shutdown, change wal_level,
> startup. A slot exists but won't work correctly.
It seems to me that what we are looking for is just to complain at
startup if we find any slot data and if trying to start up with
wal_level = minimal.
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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-10-30 03:01:23 | Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line |
Previous Message | Michael Paquier | 2018-10-30 02:39:31 | Re: Conflicting option checking in pg_restore |