Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Aug 25, 2016 at 9:48 AM, Stephen Frost <sfr...@snowman.net> wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> Meanwhile, we'll significantly help people who are currently > >> generating painfully large but not totally insane numbers of WAL > >> segments. Someone who is currently generating 32,768 WAL segments per > >> day - about one every 2.6 seconds - will have a significantly easier > >> time if they start generating 8,192 WAL segments per day - about one > >> every 10.5 seconds - instead. It's just much easier for a reasonably > >> simple archive command to keep up, "ls" doesn't have as many directory > >> entries to sort, etc. > > > > I'm generally on-board with increasing the WAL segment size, and I can > > see the point that we might want to make it more easily configurable as > > it's valuable to set it differently on a small database vs. a large > > database, but I take exception with the notion that a "simple archive > > command" is ever appropriate. > > My point wasn't really that archive_command should actually be simple. > My point was that if it's being run multiple times per second, there > are additional challenges that wouldn't arise if it were being run > only every 5-10 seconds.
My point was that the concerns about TCP/ssh startup costs, which was part of your point #1 in your initial justification for the change, have been addressed through tooling. > I guess I should have said "simpler" rather than "reasonably simple", > because there's nothing simple about setting archive_command properly. Agreed. > I mean, it could only actually be simple if somebody had a good a > backup tool that provided an archive_command that you could just drop > in place. But I'm sure if somebody had such a tool, they'd take every > opportunity to bring it up, so we doubtless would have heard about it > by now. Right? :-) Thankfully there's actually multiple good open source and freely available tools that address this issue (albeit, through different mechanisms). Thanks! Stephen
signature.asc
Description: Digital signature
