Re: Libpq support to connect to standby server as priority

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
Cc: Greg Nancarrow <gregn4422(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dave Cramer <pg(at)fastcrypt(dot)com>, Jing Wang <jingwangian(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Elvis Pranskevichus <elprans(at)gmail(dot)com>
Subject: Re: Libpq support to connect to standby server as priority
Date: 2020-01-09 15:25:39
Message-ID: 20200109152539.GA29017@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-Jan-06, tsunakawa(dot)takay(at)fujitsu(dot)com wrote:

> Let me check my understanding. Are you proposing these?
>
> * The canonical libpq connection parameter is target_session_attr = {primary | standby | prefer-standby}. Leave and document read-write as a synonym for primary.
>
> * When the server version is 13 or later, libpq just checks in_recovery, not checking transaction_read_only or sending SHOW transaction_read_only.
>
> * When the server version is before 13, libpq sends SHOW transaction_read_only as before.

Yes, that sounds good to me.

> Personally, 100% agreed, considering what we really wanted to do when target_session_attr was introduced is to tell if the server is primary or standby. The questions are:
>
> Q1: Should we continue to use the name target_session_attr, or rename it to target_server_type and make target_session_attr a synonym for it? I'm in favor of the latter.

I'm not 100% sure about this. I think part of the reason of making it
target_session_attrs (note plural) is that the user could be able to
specify more than one attribute (a comma-separated list, like the
DateStyle GUC), if we supported some hypothetical attributes in the
future that are independent of the existing ones. I'm not inclined to
break that, unless the authors of the original feature agree to that.

Maybe one possible improvement would be to add target_server_type as an
additional one, that only accepts a single item (primary/standby/prefer-standby),
as a convenience, while target_session_attrs retains its ability to
receive more than one value. The two would be somewhat redundant but
not exact synonyms.

> Q2: Can we accept the subtle incompatibility that
> target_session_attr=read-write and target_server_type=primary are not
> the same, when default_transaction_read_only is on? (I'd like to hear
> yes)

... on servers versions 12 and older, yes. (If I understand correctly,
we wouldn't have such a difference in version 13).

> Q3: Can we go without supporting standby and prefer-standby for older
> servers? (I think yes because we can say that it's a new feature
> effective for new servers.)

Yes.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-01-09 15:30:58 Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Previous Message Tom Lane 2020-01-09 15:25:22 Re: logical decoding : exceeded maxAllocatedDescs for .spill files