On Thu, Nov 24, 2016 at 7:16 AM, Mithun Cy <mithun.cy@enterprisedb.com> wrote:
> On Wed, Nov 23, 2016 at 10:19 PM, Catalin Iacob <iacobcatalin@gmail.com>
> wrote:
> On Tue, Nov 22, 2016 at 8:38 AM, Tsunakawa, Takayuki
> <tsunakawa.takay@jp.fujitsu.com> wrote:
> >> If you want to connect to a server where the transaction is read-only,
> then shouldn't the connection parameter be something like
>>>"target_session_attrs=readonly"? That represents exactly what the code
> does.
>
> >FWIW I find this to be a reasonable compromise. To keep the analogy
> >with the current patch it would be more something like
> "target_session_attrs=read_write|any".
>
> I have taken this suggestion now renamed target_server_type to
> target_session_attrs with possible 2 values "read-write", "any".
I didn't hear any objections to this approach and, after some thought,
I think it's good. So I've committed this after rewriting the
documentation, some cosmetic cleanup, and changing the logic so that
if one IP for a host turns out to be read-only, we skip all remaining
IPs for that host, not just the one that we tested already. This
seems likely to be what users will want.
I recognize that this isn't going to be please everybody 100%, but
there's still room for followup patches to improve things further.
One thing I really like about the target_session_attrs renaming is
that it seems to leave the door open to a variety of things we might
want to do later. The "read-write" value we now support is closely
related to the query we use for testing ("show
transaction_read_only"). If we later want to filter based on some
other server property, we can add additional values with associated
SQL commands for each. Of course that could get a little crazy if
overdone, but hopefully we won't overdo it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company