* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Aug 25, 2016 at 10:34 AM, Stephen Frost <sfr...@snowman.net> wrote: > >> 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. > > It's good to know that some tool sets have addressed that, but I'm > pretty certain that not every tool set has done so, probably not even > all of the ones in common use. Anyway, I think the requirements we > impose on archive_command today are just crazy. All other things > being equal, changes that make it easier to write a decent one are > IMHO going in the right direction.
Agreed, but, unfortunately, this isn't an "all other things being equal" case, or we wouldn't be having this discussion. Increasing the WAL segment size means it'll be longer before archive_command is called which means there's a larger amount of potential data loss for users who are using it without any other archiving/replication solution, along with the other concerns about it possibly resulting in a higher disk space cost. I agree that increasing it makes sense and that 64MB is a good number, but I wouldn't want to go much higher than that. That doesn't completely solve the TCP/SSH start-up cost penalty as there will be environments where that is still expensive even with 64MB WAL segments, but it will certainly be reduced. To try to summarize, I don't think we should be trying to solve the TCP/SSH start-up penalty issue for all users by encouraging them to increase the WAL segment size, at least not without covering the trade-offs. That isn't to say we shouldn't change the default, I agree that we should, but I believe we should keep it a reasonably conservative change and if we make it user-configurable then we need to be sure to document the trade-offs. Thanks! Stephen
signature.asc
Description: Digital signature
