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@truschnigg.info )
www: https://johannes.truschnigg.info/
phone: +43 650 2 133337
xmpp: johannes@truschnigg.info
Please do not bother me with HTML-email or attachments. Thank you.