Re: Automatic cleanup of oldest WAL segments with pg_receivexlog

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Automatic cleanup of oldest WAL segments with pg_receivexlog
Date: 2017-03-06 22:16:04
Message-ID: CA+TgmoZfrrU_GucPiKUDNFyxDZyg24TFEB9A6UdjeubgHL-Keg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 6, 2017 at 3:26 PM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 3/4/17 02:09, Michael Paquier wrote:
>> Well, that's one reason why I was thinking that having an independent
>> in-core option to clean up the tail of the oldest segments is
>> interesting: users don't need to maintain their own infra logic to do
>> anything. Now this end-segment command can as well be used with a
>> small binary doing this cleanup, but the monitoring of the thing gets
>> harder as multiple processes get spawned.
>
> I think the initial idea of having an option that does something
> specific is better than an invitation to run a general shell command. I
> have some doubts that the proposal to clean up old segments based on
> file system space is workable. For example, that assumes that you are
> the only one operating on the file system. If something else fills up
> the file system, this system could then be induced to clean up
> everything immediately, without any reference to what you still need.
> Also, the various man pages about statvfs() that I found are pretty
> pessimistic about how portable it is.

What if we told pg_receivewal (or pg_receivexlog, whatever that is) a
maximum number of segments to retain before removing old ones? Like
pg_receivewal --limit-retained-segments=50GB, or something like that.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-03-06 22:19:29 Re: Performance degradation in TPC-H Q18
Previous Message Andres Freund 2017-03-06 22:15:14 Need a builtin way to run all tests faster manner