Horton

Re: replication_slots usability issue

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, "Joshua D. Drake" <jd@commandprompt.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-10-30T17:52:54Z
Lists: pgsql-hackers 
On 2018-10-30 11:51:09 +0900, Michael Paquier wrote:
> 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.

Right, we really should just call CheckSlotRequirements() before doing
so. I'll make it so, once I'm actually awake and had some coffee.


> 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. I guess we can change it,
but I'd only do so in master.


Greetings,

Andres Freund

Commits

  1. Fix copy-paste error in errhint() introduced in 691d79a07933.

  2. Lower error level from PANIC to FATAL when restoring slots at startup

  3. Fix error message typo introduced 691d79a07933.

  4. Disallow starting server with insufficient wal_level for existing slot.

  5. Allow replication slots to be dropped in single-user mode