On Mon, Oct 30, 2017 at 7:04 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: >> A sort of middle way would be to keep the secondary checkpoint around >> but never try to replay from that point, or only if a specific flag is >> provided. > > Why do you want to keep the secondary checkpoint? If there is no way to > automatically start a recovery from the prior checkpoint, is it really > possible to do the same manually? I think the only advantage of keeping > it is that the WAL files are kept around for a little bit longer. But > is that useful? Surely for any environment where you really care, you > have a WAL archive somewhere, so it doesn't matter if files are removed > from the primary's pg_xlog dir.
(apologies for the empty message) I don't really want anything in particular here, other than for the system to be reliable. If we're confident that there's zero value in the secondary checkpoint then, sure, ditch it. Even if you have the older WAL files around in an archive, it doesn't mean that you know where the previous checkpoint start location is ... but actually, come to think of it, if you did need to know that, you could just run pg_waldump to find it. That probably wasn't true when this code was originally written, but it is today. I was mostly just thinking out loud, listing another option rather than advocating for it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers