On Thu, Jan 5, 2017 at 8:39 PM, Beena Emerson <memissemer...@gmail.com> wrote: > On Tue, Jan 3, 2017 at 5:46 PM, Michael Paquier <michael.paqu...@gmail.com> > wrote: >> Actually, why not just having an equivalent of the SQL >> command and be able to query parameter values? > > This patch only needed the wal_segment_size and hence I made this specific > command. > How often and why would we need other parameter values in the replication > connection? > Making it a more general command to fetch any parameter can be a separate > topic. If it gets consensus, maybe it could be done and used here.
I concur that for this patch it may not be necessary. But let's not narrow us in a corner when designing things. Being able to query the value of parameters is something that I think is actually useful for cases where custom GUCs are loaded on the server's shared_preload_libraries to do validation checks (one case is a logical decoder on backend, with streaming receiver as client expecting the logical decoder to do a minimum). This can allow a client to do checks only using a replication stream. Another case that I have in mind is for utilities like pg_rewind, we have been discussing about being able to not need a superuser when querying the target server. Having such a command would allow for example pg_rewind to do a 'SHOW full_page_writes' without the need of an extra connection. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
