Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, May 5, 2021 at 4:13 PM Stephen Frost <sfr...@snowman.net> wrote: > > That said, in an ideal world, we'd have a way to get the new timeline to > > switch to in a way that doesn't leave open race conditions, so as long > > we're talking about big changes to the way archiving and archive_command > > work (or about throwing out the horrible idea that is archive_command in > > the first place and replacing it with appropriate hooks such that > > someone could install an extension which would handle archiving...), I > > would hope we'd have a way of saying "please, atomically, go get me a new > > timeline." > > > > Just as a reminder for those following along at home, as I'm sure you're > > already aware, the way we figure out what timeline to switch to when a > > replica is getting promoted is that we go run the restore command asking > > for history files until we get back "nope, there is no file named > > 0000123.history", and then we switch to that timeline and then try to > > push such a history file into the repo and hope that it works. > > Huh, I had not thought about that problem. So, at the risk of getting > sidetracked, what exactly are you asking for here? Let the extension > pick the timeline using an algorithm of its own devising, rather than > having core do it? Or what?
Having the extension do it somehow is an interesting idea and one which might be kind of cool. The first thought I had was to make it archive_command's job to "pick" the timeline by just re-trying to push the .history file (the actual contents of it don't change, as the information in the file is about the timeline we are switching *from* and at what LSN). That requires an archive command which will fail if that file already exists though and, ideally, would perform the file archival in an atomic fashion (though this last bit isn't stricly necessary- anything along these lines would certainly be better than the current state). Having an entirely independent command/hook that's explicitly for this case would be another approach, of course, either in a manner that allows the extension to pick the destination timeline or is defined to be "return success only if the file is successfully archived, but do *not* overwrite any existing file of the same name and return an error instead." and then the same approach as outlined above. Thanks, Stephen
signature.asc
Description: PGP signature
