pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Alex Balashov <abalashov@evaristesys.com>
To: pgsql-admin@postgresql.org
Cc: pgsql-admin@postgresql.org
Subject: Re: Physical replication slots and xlog space exhaust
Date: Mon, 29 Apr 2019 06:44:20 -0400
Message-ID: <20190429104420.GA28142@typhoon> (raw)
In-Reply-To: <CAC+AXB0RSUTKnwz73mrArS6FjfftS8=DY2WKhXywjrYjQ3C=LQ@mail.gmail.com>
References: <5C492AE6-272A-451D-9563-59A93162F2E6@evaristesys.com>
	<CAC+AXB0RSUTKnwz73mrArS6FjfftS8=DY2WKhXywjrYjQ3C=LQ@mail.gmail.com>

On Mon, Apr 29, 2019 at 12:30:01PM +0200, Juan José Santamaría Flecha wrote:

> > We I understand the ultimate solution to this is to mind one’s replication
> > slots and monitor disk usage fastidiously, but is there a config parameter
> > for the maximum overall amount of transaction logs that can be kept
> > accumulated on the master, irrespectively of physical replication slots
> > commitments?
> >
> 
> Doing that would break the desired functionality of replication slots.
> There is a caution note about this behaviour in the documentation [1].
> 
> Using the pg_replication_slots view you can check which slot is active or
> if there is a good candidate for dropping.
> 
> Or you can take a more traditional approach using the wal_keep_segments
> parameter instead of slots.

Hi,

While these are physical rather than logical replication slots, you seem
to be correct:

https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION-SLOTS

   "In lieu of using replication slots, it is possible to prevent the
    removal of old WAL segments using wal_keep_segments, or by storing the
    segments in an archive using archive_command. However, these methods
    often result in retaining more WAL segments than required, whereas
    replication slots retain only the number of segments known to be needed.
    An advantage of these methods is that they bound the space requirement
    for pg_wal; there is currently no way to do this using replication
    slots."

I suppose, as usual, I would have been wise to simply RTFM. :-) 

Thank you for your feedback!

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/





view thread (2+ messages)

Message-ID: <20190429104420.GA28142@typhoon>
Permalink:  ../20190429104420.GA28142@typhoon/
Also on:    postgresql.org/message-id/20190429104420.GA28142@typhoon

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: abalashov@evaristesys.com
  Subject: Re: Physical replication slots and xlog space exhaust
  In-Reply-To: <20190429104420.GA28142@typhoon>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox