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 1qH2hL-0006Qs-6z for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Jul 2023 13:37:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qH2hJ-0001qb-Rj for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Jul 2023 13:37:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qH2hI-0001qO-81 for pgsql-hackers@lists.postgresql.org; Wed, 05 Jul 2023 13:37:33 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qH2hE-002Azn-IF for pgsql-hackers@lists.postgresql.org; Wed, 05 Jul 2023 13:37:31 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1AC985C016C; Wed, 5 Jul 2023 09:37:27 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 05 Jul 2023 09:37:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eulerto.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1688564247; x=1688650647; bh=j5 qa5bUGtAnAeMkSRFKNShHPdf7XTkggnE+bClHD79o=; b=XitM7Vz7GNxPZ7S61G pjQsgc1fY8ZqCg2dB+si4ZrxNTM2C0NYu1UWuPWqsMkIY6WjHIeugX+6AcKaQ+wC XrQ7iCyvF7k3iDE3ggeJrlFe/KmoaHJs5ITT0kMNSlakC+WrOMowLzqENC4pVlEP TrA04Kxn3KiNs6np7QtX04g2GiuOQGx2j2OUTnEzgpEJAfBYiEy2Vp6OlkADCi3L H0MUQmCH/ZYtT6qntNtrij4/K2IpxGCVspPtLgEW86y95IN48sXrTTYk5t0jwxN2 H1jkRS4WmaljjEbVHI7eOsg7lKKfNBcJ+S2gF3kzs6L9pYgEN4ZMXsByzT5Q8ibK L4bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1688564247; x=1688650647; bh=j5qa5bUGtAnAe MkSRFKNShHPdf7XTkggnE+bClHD79o=; b=BbZAabsumr3ux+x20QHFLPTN0kjhk y3Ut+LzqGZp+lCpiCn0jPHapnUAnfqVdhzgUwFxE1g/MXo4S5ZRhrHr/ls0Ja7N0 11y643VKcE/OT7rFC2moTVeQ/8o7DhVUzI8Na0TGoW9o7A0iTK9bDcZ0JhEe4mlU EI6C/KvMXK39WJ4xlGbcLho4iuEFs5/OkmWKsI2t1ds9ww/jPBvnIHFXr4LEU7I+ C6M4gBYX+2tZwQkfyAOdUHxJX1Gke2xXcZisK7G4JQjct4BiLhzVEY+x9UOI7tg2 RPDlU0YgStD2xI7NH++xhqpmjfcQNdeKS3qEko6KAtf/kuoqAKMT3tAhg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudejgddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreertdenucfhrhhomhepfdfguhhl vghrucfvrghvvghirhgrfdcuoegvuhhlvghrsegvuhhlvghrthhordgtohhmqeenucggtf frrghtthgvrhhnpefgffejvdeivdekvdeivdetudeikeduieevtdfhhfduvdetgeelteei ffekgefhvdenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvghulhgvrhesvghu lhgvrhhtohdrtghomh X-ME-Proxy: Feedback-ID: i0c21471d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id A949D15A008E; Wed, 5 Jul 2023 09:37:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-527-gee7b8d90aa-fm-20230629.001-gee7b8d90 Mime-Version: 1.0 Message-Id: In-Reply-To: <20230705105639.lsz7ogusvkukbvs5@alvherre.pgsql> References: <20230705105639.lsz7ogusvkukbvs5@alvherre.pgsql> Date: Wed, 05 Jul 2023 10:37:05 -0300 From: "Euler Taveira" To: "Alvaro Herrera" , "Amit Kapila" Cc: pgsql-hackers@lists.postgresql.org, "Masahiko Sawada" Subject: Re: logicalrep_message_type throws an error Content-Type: multipart/alternative; boundary=965de1bba6a046aa827aa219fce32c2c List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --965de1bba6a046aa827aa219fce32c2c Content-Type: text/plain On Wed, Jul 5, 2023, at 7:56 AM, Alvaro Herrera wrote: > On 2023-Jul-05, Amit Kapila wrote: > > > I think after returning "???" from logicalrep_message_type(), the > > above is possible when we get the error: "invalid logical replication > > message type "X"" from apply_dispatch(), right? If so, then what about > > the case when we forgot to handle some message in > > logicalrep_message_type() but handled it in apply_dispatch()? Isn't it > > better to return the 'action' from the function > > logicalrep_message_type() for unknown type? That way the information > > could be a bit better and we can easily catch the code bug as well. > > Are you suggesting that logicalrep_message_type should include the > numerical value of 'action' in the ??? message? Something like this: > > ERROR: invalid logical replication message type "X" > CONTEXT: processing remote data for replication origin "pg_16638" during message type "??? (123)" in transaction 796, finished at 0/16266F8 Isn't this numerical value already exposed in the error message (X = 88)? In this example, it is: ERROR: invalid logical replication message type "X" CONTEXT: processing remote data for replication origin "pg_16638" during message type "??? (88)" in transaction 796, finished at 0/1626698 IMO it could be confusing if we provide two representations of the same data (X and 88). Since we already provide "X" I don't think we need "88". Another option, is to remove "X" from apply_dispatch() and add "??? (88)" to logicalrep_message_type(). Opinions? -- Euler Taveira EDB https://www.enterprisedb.com/ --965de1bba6a046aa827aa219fce32c2c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, Jul 5, = 2023, at 7:56 AM, Alvaro Herrera wrote:
On 2023-Jul-05, Amit Kapila wrote:

> I think after returning "???" from logicalrep_= message_type(), the
> above is possible when we get the= error: "invalid logical replication
> message type "X"= " from apply_dispatch(), right? If so, then what about
>= ; the case when we forgot to handle some message in
> l= ogicalrep_message_type() but handled it in apply_dispatch()? Isn't it
> better to return the 'action' from the function
> logicalrep_message_type() for unknown type? That way the inf= ormation
> could be a bit better and we can easily catc= h the code bug as well.

Are you suggesting = that logicalrep_message_type should include the
numerical = value of 'action' in the ??? message? Something like this:

ERROR:  invalid logical replication message type "X= "
CONTEXT:  processing remote data for replication or= igin "pg_16638" during message type "??? (123)" in transaction 796, fini= shed at 0/16266F8

Isn't this n= umerical value already exposed in the error message (X =3D 88)?
In this example, it is:

ERROR:  = invalid logical replication message type "X"
CONTEXT: = ; processing remote data for replication origin "pg_16638" during messag= e type "??? (88)" in transaction 796, finished at 0/1626698
IMO it could be confusing if we provide two representations= of the same data (X
and 88). Since we already provide "X"= I don't think we need "88". Another
option, is to remove = "X" from apply_dispatch() and add "??? (88)" to
logicalre= p_message_type().

Opinions?


--
=
Euler Taveira

--965de1bba6a046aa827aa219fce32c2c--