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/>

Reply via email to