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. I think something that works similar to pg_archivecleanup that knows what the last base backup is could work. In fact, could pg_archivecleanup not be made to work here? It's an archive, and it needs cleaning. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
