On Mon, Mar 6, 2017 at 3:26 PM, Peter Eisentraut <peter.eisentr...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
