Re: replication_slots usability issue

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

In response to

Responses

Browse pgsql-hackers by date

  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