Hi, > > Wow. I have to admit that I feel completely opposite of that- I'd > > *love* to have an independent tool (which ideally uses the same code > > through the common library, or similar) that can be run to apply WAL. > > > > In other words, I don't agree that it's the server's problem at all to > > solve that, or, at least, I don't believe that it needs to be. > > I mean, I guess I'd love to have that if I could get it by waving a > magic wand, but I wouldn't love it if I had to write the code or > maintain it. The routines for applying WAL currently all assume that > you have a whole bunch of server infrastructure present; that code > wouldn't run in a frontend environment, I think. I wouldn't want to > have a second copy of every WAL apply routine that might have its own > set of bugs.
I'll fight tooth and nail not to have a second implementation of replay, even if it's just portions. The code we have is complicated and fragile enough, having a [partial] second version would be way worse. There's already plenty improvements we need to make to speed up replay, and a lot of them require multiple execution threads (be it processes or OS threads), something not easily feasible in a standalone tool. And without the already existing concurrent work during replay (primarily checkpointer doing a lot of the necessary IO), it'd also be pretty unattractive to use any separate tool. Unless you just define the server binary as that "independent tool". Which I think is entirely reasonable. With the 'consistent' and LSN recovery targets one already can get most of what's needed from such a tool, anyway. I'd argue the biggest issue there is that there's no equivalent to starting postgres with a private socket directory on windows, and perhaps an option or two making it easier to start postgres in a "private" mode for things like this. Greetings, Andres Freund
