Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ljPDn-00014e-4U for pgsql-admin@arkaria.postgresql.org; Wed, 19 May 2021 16:38:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ljPDm-0006JY-2D for pgsql-admin@arkaria.postgresql.org; Wed, 19 May 2021 16:38:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ljPDl-0006JQ-OJ for pgsql-admin@lists.postgresql.org; Wed, 19 May 2021 16:38:57 +0000 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ljPDh-0003cx-Dz for pgsql-admin@lists.postgresql.org; Wed, 19 May 2021 16:38:57 +0000 Received: by mail-wr1-x42c.google.com with SMTP id p7so10972471wru.10 for ; Wed, 19 May 2021 09:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec.at; s=cybertec.at; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=NUOlu54x/f3HxbQ1Hvm+ANwabT2uSKhr0BtTKylf6ns=; b=ElRcONyTPL9oZHu4ddjNQaIm7QgOKjpsfL6Du3nep5pIrkk8U0BJDgiw19NWWroGX6 WQTPWRKank8Bop4dCjvgME7Nb7uLVXIOW6OpN0qHBbCbS9pS5icYpBOaqUGmqrIQrVsu PpdwkNmvwzxa9htjGJsKbBIj0+VMwKHwuLDvY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=NUOlu54x/f3HxbQ1Hvm+ANwabT2uSKhr0BtTKylf6ns=; b=t/QbEuX0DgrU8TYifG2J9DE2Z/2y67FBCgNoUX6WN108ivTWT2xRYU2wFstMows9he BUtYt2/UonhM5HOS/VvZ9yxXpsjGySa5hgAlvBQWs6DDd0xaGLO7wfIl2jyJ5vopis/W gegpaQC947vxFtQwymOwcpZKiV//qisvjPb7GYqJ5Qe1YV2FYLxIiXtk9UemPOPJYN7v wabt6ieANtZfPRKTYu8/RDR8RzcKH8gnB+3vHFG5CRy9TQr2NGEYsXA2eUA7QWWu6XMS sVnZfv4m0WsIatlVf45lV1GkrAx1hKI/FbkaybJwUCOIhgvZGVSrWstE4BtGZU6p+SjW hSLA== X-Gm-Message-State: AOAM530mhyTYoUxIizOl/qSoVj0pH1NyPWlV/PzEMKmPvIcnIW+S7L9a kKIwwII369SDZxrDntQId4IhKw== X-Google-Smtp-Source: ABdhPJxiQ2Iw7oM3B+EpmW13ylCkQPEW9895gZ8nuRvVdIMTHxEeVnAFyi+UPwOaNGd3ireXUqEZsg== X-Received: by 2002:a5d:62d0:: with SMTP id o16mr4706414wrv.164.1621442331410; Wed, 19 May 2021 09:38:51 -0700 (PDT) Received: from localhost.localdomain (217-149-173-25.nat.highway.telekom.at. [217.149.173.25]) by smtp.gmail.com with ESMTPSA id k6sm6313204wmi.42.2021.05.19.09.38.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 May 2021 09:38:51 -0700 (PDT) Message-ID: <022649eb4363dc73b2b7cc2e08946e13019f238f.camel@cybertec.at> Subject: Re: [EXTERNAL] Re: FDW, connections, master v replica From: Laurenz Albe To: "Godfrin, Philippe E" , pgsql-admin@lists.postgresql.org Date: Wed, 19 May 2021 18:38:50 +0200 In-Reply-To: References: <49ed5b6a7a44f245676db39d8c6c2b1f55035eac.camel@cybertec.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2021-05-19 at 15:45 +0000, Godfrin, Philippe E wrote: > From: Laurenz Albe > >On Tue, 2021-05-18 at 16:13 +0000, Godfrin, Philippe E wrote: > > > That seems very promising, though I’m not certain how I’d code that in the create > > > foreign server syntax. My testbed is not quire ready right now, so I’ll ask instead of testing. > > > Is this what you mean: > > > > > > CREATE SERVER FDW001 FOREIGN DATA WRAPPER POSTGES_FDW > > > OPTIONS (HOST ‘FOORW, FOORO’, DBNAME ‘FOODB,FOODB’, PORT ‘5432,6432’, > > > TARGET_SESSION_ATTRS ‘ANY,READ-ONLY’ > > > > Pretty much, yes. Except you can only specify a single setting for > > "target_session_attrs". > > OK – so using target_session_attr=’read-write’ will use the show transaction_read_only > command – if the reply is ‘on’ the connection is closed, which will then go to the next > host/port combination… > Seems to me, then, it’s the libpq operation that permits the selection… Yes, the postgres_fdw options are mostly libpq connection parameters. > Hmm, wait a minute. Then how do you segregate connections by RO ?? I can’t wait until v14 Right. If you cannot wait for v14, that is hard luck. You could use a load balancer, perhaps that can be configured to check "pg_is_in_recovery()". Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com