On 2/23/17 10:10 AM, Magnus Hagander wrote:
Wouldn't this one, along with some other scenarios, be better provided by the "run command at end of segment" function that we've talked about before? And then that external command could implement whatever aging logic would be appropriate for the environment?
That kind of API lead to difficulties with archiving direct from the database, so I'm not sure it's the best way to go.
ISTM what's really needed is a good way for users to handle retention for both WAL as well as base backups. A tool that did that would need to understand what WAL is required to safely restore a base backup. It should be possible for users to have a separate retention policy for just base backups as well as backups that support full PITR. You'd also need an easy way to deal with date ranges (so you can do things like "delete all backups more than 1 year old").
Perhaps a good starting point would be a tool that lets you list what base backups you have, what WAL those backups need, when the backups were taken, etc.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
