Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ipZgx-0007T8-QG for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 15:25:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ipZgw-0000k0-Ho for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jan 2020 15:25:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ipZgw-0000js-8m for pgsql-hackers@lists.postgresql.org; Thu, 09 Jan 2020 15:25:46 +0000 Received: from mail-qk1-x743.google.com ([2607:f8b0:4864:20::743]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ipZgt-0002AZ-Fx for pgsql-hackers@postgresql.org; Thu, 09 Jan 2020 15:25:45 +0000 Received: by mail-qk1-x743.google.com with SMTP id w127so6264974qkb.11 for ; Thu, 09 Jan 2020 07:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=iam/k9E4smZNICQexlgdNEVQstZs43wEfje/SEHL0Qc=; b=N6G9Nuwr1fkamkP4U460AyVQ1HbIud2GKrIeW9W4g7c412n9Z9frn0mAsUprYKYyBG jxL7Q/tM8gIugfviJjQrrqY2h5cHMmnIgD/toFywkq0Qu38dKU39doCjZQnB6bKwfC+1 XgroO2UbxK2zJAPUHcVhl1L2VHr+LmznVyeY5UBw+dDPWu1OaDNqa5ihxGaBNm9fbV1S aUslJkTvWeuHMe+cAYCR+YgXOQaiXt8ywipLhn2EWgnEoS842nCPnuxNuEVGEVoLbPLH VzJVxQ581lh5iUkwFDWereaW6MCoZ4ZlJzWzBMCKuDxkjxyROm6S1b9TxelA9S9y3WLM QVXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=iam/k9E4smZNICQexlgdNEVQstZs43wEfje/SEHL0Qc=; b=H1WyaaupCHH+coze4xLpVlf1mKnboEV3v0+i8WXzhql8jJR15HlNtdeiygv3UvIlvn hgSuG4IO9vS/9wAZTCSTgAU3kD74s8rcEHt+oZpZ+mVdQXAv9j8Yo43unfH4IQFwrqrN MS317B0uj0J6aq/xYcixEGeo1CpL0qUx4i2TR1pfQ2k+g/v4bbBl9KfPV5XGbXgW64f4 2a5qYAs9gUKKwiVA06xZko4RnzacCyWbDFnzlD54EYcUa7aNDYhgXTCN2SrpN2HEuMZM B1jnyZvv/m2/xhp5ugdn1D523M/p47C3yCBvEggZ7mHEs/CR1GeAFMTV4HD4QKNIBzKg mGDA== X-Gm-Message-State: APjAAAWUagSAanOW3bnNGzljelJdh+d4WaUcGxxz0hFzywPvFOjxt95I +XImLu6EKMdCup04LjO57zIEPQ== X-Google-Smtp-Source: APXvYqyskUJ+sXAyrJvlD9r2k4hm33qqO4LpoHseWrk3YlFo+8GVAH4BVQ/AoCj45ok0m6h1qSSSsA== X-Received: by 2002:a05:620a:795:: with SMTP id 21mr10237252qka.60.1578583541909; Thu, 09 Jan 2020 07:25:41 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([190.217.183.234]) by smtp.gmail.com with ESMTPSA id q130sm3099201qka.114.2020.01.09.07.25.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jan 2020 07:25:41 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 4B721300827; Thu, 9 Jan 2020 12:25:39 -0300 (-03) Date: Thu, 9 Jan 2020 12:25:39 -0300 From: Alvaro Herrera To: "tsunakawa.takay@fujitsu.com" Cc: Greg Nancarrow , Haribabu Kommi , Robert Haas , Laurenz Albe , Tom Lane , Dave Cramer , Jing Wang , PostgreSQL-development , Elvis Pranskevichus Subject: Re: Libpq support to connect to standby server as priority Message-ID: <20200109152539.GA29017@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Jan-06, tsunakawa.takay@fujitsu.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