Simon Riggs <si...@2ndquadrant.com> wrote: > So we're proposing adding parameters to simplify things for users? I think it's a matter of having parameters which do simple, clear things; rather than magically interacting to guess what the user wants. What do you want to log? How many connections to you want to allow for streaming it? What's your script for sending it in archive file format? Is archiving turned on at the moment? Let's have GUC for each question, rather than having to work backwards from what you want to which combination of GUC settings gets you to that, or at least as close as the magic interpretation allows. > I don't think fiddling is going to improve things significantly > from a usability perspective, especially at the last minute. If it involves changing the internal variables in a dangerous way, perhaps we should settle for whatever we have at the moment. If it's a matter of how they get set from the GUCs, that doesn't sound very risky to me. Perhaps there are combinations which were previously disallowed which would need to be tested, but are there any other risks? > [ad hominem digression] Please, can we keep it to the merits? It sounds like there are several reasonable use-cases which could be handled by HS/SR except for how our GUCs are set up for it. Why limit the uses to a subset of where it can be useful? I'm extraordinarily busy right now, which is why my skimming of these threads didn't alert me to the problem sooner. For that I apologize. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
