On Wed, Dec 12, 2018 at 1:13 PM David Steele <da...@pgmasters.net> wrote: > On 12/11/18 11:06 PM, Robert Haas wrote: > > On Wed, Dec 12, 2018 at 11:29 AM Michael Paquier <mich...@paquier.xyz> > > wrote: > >> I really don't think that it is a good idea to link a future timeline > >> within a segment which includes in its name a direct reference to its > >> current timeline. Also I don't buy much the argument that those > >> segments are a nuisance as well all the time. They may be for some > >> tools, however not for others depending on the archiving strategy > >> (distributed locations for example), and if they are a problem for your > >> deployments, why not just discarding them within the archive command and > >> be done with them? > > > > -1. Writing an archive_command already requires a PhD in > > PostgreSQL-ology. The very last thing we should do is invent even > > more ways for an archive command to be subtly wrong. > > The point here is to make archive commands simpler. As it is, the > various backup tools are going to need to find ways to deal with the > problem, and each solution will be different. > > The goal is to come up with a solution that works and that all archive > commands can use, rather than each one rolling their own solution.
I understand. I'm more or less agreeing with you. Actually, I'm not really sure whether your particular proposal is the best way of handling this, but I disagree with Michael's suggestion that we should just throw responsibility back on archive_command. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
