Date: Tue, 31 Jul 2018 15:21:27 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Bruce Momjian <bruce@momjian.us>,
	Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
	pgsql-hackers@lists.postgresql.org, thomas.munro@enterprisedb.com,
	sk@zsrv.org, michael.paquier@gmail.com,
	peter.eisentraut@2ndquadrant.com
Subject: Re: [HACKERS] Restricting maximum keep segments by repslots
Message-ID: <20180731192127.GF27724@tamriel.snowman.net>
References: <20180129.192634.217484965.horiguchi.kyotaro@lab.ntt.co.jp>
 <20180129.194023.228030941.horiguchi.kyotaro@lab.ntt.co.jp>
 <20180319.170948.139803971.horiguchi.kyotaro@lab.ntt.co.jp>
 <20180626.162659.223208514.horiguchi.kyotaro@lab.ntt.co.jp>
 <20180731191152.GA2791@momjian.us>
 <20180731191403.satjiy4i3ce3voqs@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Hrfm+Jdo2XWOXFAf"
Content-Disposition: inline
In-Reply-To: <20180731191403.satjiy4i3ce3voqs@alap3.anarazel.de>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--Hrfm+Jdo2XWOXFAf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Andres Freund (andres@anarazel.de) wrote:
> On 2018-07-31 15:11:52 -0400, Bruce Momjian wrote:
> > On Tue, Jun 26, 2018 at 04:26:59PM +0900, Kyotaro HORIGUCHI wrote:
> > > Hello. This is the reabased version of slot-limit feature.
> > >=20
> > > This patch limits maximum WAL segments to be kept by replication
> > > slots. Replication slot is useful to avoid desync with replicas
> > > after temporary disconnection but it is dangerous when some of
> > > replicas are lost. The WAL space can be exhausted and server can
> > > PANIC in the worst case. This can prevent the worst case having a
> > > benefit from replication slots using a new GUC variable
> > > max_slot_wal_keep_size.
> >=20
> > Have you considered just using a boolean to control if max_wal_size
> > honors WAL preserved by replication slots, rather than creating the new
> > GUC max_slot_wal_keep_size?
>=20
> That seems like a bad idea. max_wal_size influences checkpoint
> scheduling - there's no good reason to conflate that with retention?

I agree that we shouldn't conflate checkpointing and retention.  What I
wonder about though is what value will wal_keep_segments have once this
new GUC exists..?  I wonder if we could deprecate it...  I wish we had
implemented repliation slots from the start with wal_keep_segments
capping the max WAL retained but that ship has sailed and changing it
now would break existing configurations.

Thanks!

Stephen

--Hrfm+Jdo2XWOXFAf
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJbYLa3AAoJEO1sijiDR2RVX3kQAMUqQCuRfEkTebXgFFv1F43U
QHk8KFK0FOgF2HOxQRemXLNawnnwIcc2fEEHwJ8xeqF6/3DFuLljfjGFNGUB0mIr
jy4cJn/x9oX5y+tBTWWQU12hNH37IHkiFaouTh3mRRH33rDKJHW+KE9gmaZ1rxA4
FvYBEGr6jIIAShc+ST8eC9ZMQ+MYe2rajMsi+MGN9NKR+QJ9pIIwsEKDutHnTihP
LIWNMtjOIt3k2p2zHEOxX59h/t8W5p1sxomWnsf8WByaNlWmmkbzcO/DwJy0IJit
wCel6PEa02KjIwUhrix+Fq6YnQw4lRdY740UcoId4+GbG3AKgcBH1t0JFeYmG4sC
NwJOMl1G98dYqO09JIYzg/7wxf2w8gQdFbyKLDXbEQY6CHodiRtKOfVDa5rpLNU+
6WtsrnVQqC+ROLbPI7kgqZcIhNBWU5tqH2CzmLk1L8FOTua8jcPmMNyr02KkIoMA
UKjgjaqIjOcrEZZHLpAV+Z3pqyptCDg1u1RjBW/Cf1oBAH6ca/cv/wg1QXvAcIH3
3164q4F9HBiUIRn5VhTZuKUU/6oVFIUgGhcW8ulRWlcxnURBb8H2X9IxxK+A/VAf
KT/JPZ8ezmYoWlWndIoV58L8OYjUMF44YgxrkUimhdu3tmXyockWc0NxPFASNc21
XpuBfB9++/n3zge61EAX
=cPPF
-----END PGP SIGNATURE-----

--Hrfm+Jdo2XWOXFAf--