On Thu, Mar 23, 2017 at 4:50 AM, Magnus Hagander <magnus@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.
