On Thu, Nov 24, 2016 at 7:16 AM, Mithun Cy <mithun...@enterprisedb.com> wrote: > On Wed, Nov 23, 2016 at 10:19 PM, Catalin Iacob <iacobcata...@gmail.com> > wrote: > On Tue, Nov 22, 2016 at 8:38 AM, Tsunakawa, Takayuki > <tsunakawa.ta...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers