Re: increasing the default WAL segment size

On Fri, Jan 6, 2017 at 11:36 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Thu, Jan 5, 2017 at 8:39 PM, Beena Emerson <memissemerson(at)gmail(dot)com>
> wrote:
> > On Tue, Jan 3, 2017 at 5:46 PM, Michael Paquier <
> michael(dot)paquier(at)gmail(dot)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!