On Wed, Feb 27, 2019 at 02:57:46PM +0200, Achilleas Mantzios wrote: > > [...] > A logical approach for replication slots would be to accept a parameter > regarding max WAL files to retain, after which newer WALs will be removed > and the primary server saved. Pretty much like : --archive-push-queue-max > argument of pgbackrest . Before replication slots where a thing, you had to carefully balance wal_keep_segments in regard to WAL production or/and (usually and :)) set up a proper WAL archive for replication to be able to soldier on even after a WAL receiver experienced service-interrupting trouble for a while. The benefit of that was that the WAL producer remained unaffected (unless you bungled the archiving process profoundly) of such calamities. To me, that was the preferred trade-off for all use-cases of replication that I personally encountered. If it were possible to have the best of both worlds (i.e. have a kind of "high water mark number of WAL segments"-setting per replication slot, over which the slot would be abandoned - with a heavy heart and lots of screaming in the logs, of course - by the producer), that sure would be awesome. But at this time, we are where we are :) -- with best regards: - Johannes Truschnigg ( johannes@xxxxxxxxxxxxxxx ) www: https://johannes.truschnigg.info/ phone: +43 650 2 133337 xmpp: johannes@xxxxxxxxxxxxxxx Please do not bother me with HTML-email or attachments. Thank you.
Attachment:
signature.asc
Description: PGP signature
