On Wed, Apr 5, 2017 at 6:22 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Mar 23, 2017 at 4:50 AM, Magnus Hagander <mag...@hagander.net> > wrote: > > One thing we might want to consider around this -- in 10 we have > > target_session_attrs=read-write (since > > 721f7bd3cbccaf8c07cad2707826b83f84694832), which will issue a SHOW > > transaction_read_only on the connection. > > > > We should probably consider if there is some way we can implement these > two > > things the same way. If we're inventing a new variable that gets pushed > on > > each connection, perhaps we can use that one and avoid the SHOW command? > > I think that would be a good idea. It was, in fact, proposed to do > exactly that as part of the patch that added > target_session_attrs=read-write, but we ended up not doing anything > about it because the SHOW mechanism would still be needed when > connecting to pre-10 versions of PostgreSQL. Therefore, it seemed > like a separate improvement. But if we're adding a GUC_REPORT value > that could be used for the same or a similar purpose, I think it would > make sense to consider revising that mechanism to leverage it as well, > obviously only on releases that have the GUC. > > Based on that we seem to agree here, should we add this as an open item? Clearly if we want to change this, we should do so before 10. I also came up with another case where the current one won't work but it could be really useful -- if we make a replication connection (with say pg_receivewal) it would be good to be able to say "i want the master" (or "i want a standby") the same way. And that will fail today if it needs SHOW to work, right? So having it send that information across in the startup package when talking to a 10 server, but falling back to using SHOW if talking to an earlier server, would make a lot of sense I think. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
