RE: Libpq support to connect to standby server as priority - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Libpq support to connect to standby server as priority
Date
Msg-id 0A3221C70F24FB45833433255569204D1FB69730@G01JPEXMBYT05
Whole thread Raw
In response to Re: Libpq support to connect to standby server as priority  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Libpq support to connect to standby server as priority
Re: Libpq support to connect to standby server as priority
List pgsql-hackers
From: Laurenz Albe [mailto:laurenz.albe@cybertec.at]
> I think that transaction_read_only is good.
> 
> If it is set to false, we are sure to be on a replication primary or
> stand-alone server, which is enough to know for the load balancing use case.

As Tatsuo-san said, setting default_transaction_read_only leads to a misjudgement of the primary.


> I deem it unlikely that someone will set default_transaction_read_only to
> FALSE and then complain that the feature is not working as expected, but
> again
> I cannot prove that claim.

I wonder what default_transaction_read_only exists for.  For maing the database by default and allowing only specific
usersto write to the database with "CREATE/ALTER USER SET default_transaction_read_only = false"?
 

I'm sorry to repeat myself, but anyway, I think we need a method to connect to a standby as the original desire,
becausethe primary instance may be read only by default while only limited users update data.  That's for reducing the
burdonon the primary and minimizing the impact on users who update data.  For example,
 

* run data reporting on the standby
* backup the database from the standby
* cascade replication from the standby



> As Robert said, transaction_read_only might even give you the option to
> use the feature for more than just load balancing between replication master
> and standby.

What use case do you think of?  If you want to load balance the workload between the primary and standbys, we can
followPgJDBC -- targetServerType=any.
 


Regards
Takayuki Tsunakawa



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Shouldn't current_schema() be at least PARALLEL RESTRICTED?
Next
From: Masahiko Sawada
Date:
Subject: Fix function name in commet in vacuumlazy.c