On Fri, Jan 6, 2017 at 11:36 AM, Michael Paquier <michael.paqu...@gmail.com> wrote:
> 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. > > I see the point. I will change the SHOW_WAL_SEGSZ to a general SHOW command in the next version of the patch. Thank you, Beena Emerson Have a Great Day!