Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uoiCT-008lEp-60 for pgpool-hackers@arkaria.postgresql.org; Wed, 20 Aug 2025 12:45:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uoiCS-008A1I-Kv for pgpool-hackers@arkaria.postgresql.org; Wed, 20 Aug 2025 12:45:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uoiCS-008A1A-FJ for pgpool-hackers@lists.postgresql.org; Wed, 20 Aug 2025 12:45:57 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uoiCQ-000qTc-1u for pgpool-hackers@lists.postgresql.org; Wed, 20 Aug 2025 12:45:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Content-Transfer-Encoding:Content-Type: Mime-Version:References:In-Reply-To:From:Subject:Cc:To:Message-Id:Date:Sender :Reply-To:Content-ID:Content-Description; bh=ByydTHWF4kat6f0XiS0RT0GdfKLlETUBnXN4QLy7Ewk=; b=yVpUSQd0EkuNoVEd+Pg8XWxmFu KPHswqaE1faT7ceSjAG1LGRM/P/xTu8wbAmpsCKofFlOlelcj2tZCtgEC7DROcnM2fi23oFG+byMD YEMYCGY+WnySpSr1rbeMKkBgNrFUc3jNCnFB8EszU5InMl20f1qHjAkS6bxL3uYrSvKjXv7YWaJhA NyMDZ/u+sS8S4SLjyevtOokiZW/Sk5CXbIc6asY8S5aJF4+qFfeC1Gaxr1QHxI0BUKaL7jzIynI+5 2OBKjq3V+mdTP3feWSE+7WmfQvAIAePYC8153mDxmHVY+qNE7RPgJ0dpMkHQ+X3Qt6Oko0xGnEfHE 88hpY/kg==; Received: from [2409:11:4120:300:73ac:529f:7809:ce4c] (helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1uoiCN-0023AI-0b; Wed, 20 Aug 2025 12:45:54 +0000 Date: Wed, 20 Aug 2025 21:45:37 +0900 (JST) Message-Id: <20250820.214537.1156323467943836247.ishii@postgresql.org> To: nadav@tailorbrands.com Cc: pgpool-hackers@lists.postgresql.org Subject: Re: Proposal: recent access based routing for primary-replica setups From: Tatsuo Ishii In-Reply-To: References: <20250818.215106.1325564662459771705.ishii@postgresql.org> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2409:11:4120:300:73ac:529f:7809:ce4c (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Nadav, Thank you for the answer. I think your proposal actually includes two orthogonal proposals. (1) "inject" replication delay value from external source (in your case from Aurora). (2) per relation recent access based routing. I suggest to implement (1) first, then (2). This incremental approach would be easier than implementing (1)+(2) at once. For (1) we could add new pgpool.conf parameter, say "replication_delay_source". If it is set to "builtin", then replication delay source is PostgreSQL as we already does today. If it's set other than "builtin", then it's an external command name (+ arguments) to be executed to import replication delay value. The command should return replication delay value represented in strings like "0 20 10", which means node 0, 1 and 2 replication delay values in millisecond (in this case since the node 0 is primary, its replication delay is 0). The command will be invoked every sr_check_period. I am not sure if this actually works in Aurora. This is just a quick idea. (2) would be probably much harder than (1). So we need more discussion later on. Best regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp