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 1t62WR-00AFI3-M5 for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Oct 2024 06:49:40 +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 1t62WP-005wO8-0d for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Oct 2024 06:49:37 +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 1t62WO-005wO0-Lj for pgsql-hackers@lists.postgresql.org; Wed, 30 Oct 2024 06:49:37 +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.94.2) (envelope-from ) id 1t62WM-003a21-Gf for pgsql-hackers@postgresql.org; Wed, 30 Oct 2024 06:49:35 +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=0OjhW9F1N28g2xePTTrWxHf5Q2miCHv0lAShiF4eBxA=; b=ENofXPnnuDUZi/0evBhIcyhy/P L+RgH/U0Y9DGBjpB/Qs/YW78dfu/Wl1SnRBZnTJjYfqzCO3fKZm6094lq5ypLinA0VF5mscaFNmMT 59eCbG7RftjNaRrX6U9t/pDCYE8M32MqZbXyZ/jTFVhvXfNEyuEXLQ1tNVMtX+O309CbGvHKAoNCE 5RtPUNfCjaoTCh661OZ5jw/iNaJ/Hhayru/TiTLOFaHbQxola6P4HDDMNkR5bsLVgVu1ePH5Hf/T/ 4wPDWal1+kCBfOdMqLwvIVp64tstu65au95c8CslFd0b2yHuXridU+xZkhsgojJceKhhZgd9vYh/V +t4e7rNQ==; Received: from [2409:11:4120:300:a184:8b3c:3a29:9113] (helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.94.2) (envelope-from ) id 1t62WI-00Dxnc-3E; Wed, 30 Oct 2024 06:49:33 +0000 Date: Wed, 30 Oct 2024 15:49:19 +0900 (JST) Message-Id: <20241030.154919.859856957033404666.ishii@postgresql.org> To: peter@eisentraut.org Cc: pgsql-hackers@postgresql.org Subject: Re: protocol-level wait-for-LSN From: Tatsuo Ishii In-Reply-To: References: <8e6ba982-fd41-4779-8729-eb120df69ea0@eisentraut.org> <20241029.140600.1382327295267983604.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:a184:8b3c:3a29:9113 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk >>> With this protocol extension, two things are changed: >>> >>> - The ReadyForQuery message sends back the current LSN. >> If other protocol extension X tries to add something to the >> ReadyForQuery message too, what would happen? > > I think one would have to define that somehow. If it's useful, the > additional fields of both extensions could be appended, in some > defined order. But this is an interesting question to think about. I think this kind of extension, which adds new filed to an existing message type, should be implemented as v4 protocol. Best reagards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp