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 1jfzPA-0007e0-Jm for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jun 2020 05:24:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzP9-0005Yo-5t for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jun 2020 05:24:03 +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 1jfzP8-0005Yd-VV for pgsql-hackers@lists.postgresql.org; Tue, 02 Jun 2020 05:24:02 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jfzP1-0003r4-3a for pgsql-hackers@postgresql.org; Tue, 02 Jun 2020 05:24:00 +0000 Received: from hnk.local (p1864124-ipbf1405funabasi.chiba.ocn.ne.jp [123.216.143.124]) by oss.nttdata.com (Postfix) with ESMTPSA id DB50F60146; Tue, 2 Jun 2020 14:23:50 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com Subject: Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 To: Michael Paquier , Masahiko Sawada Cc: Kyotaro Horiguchi , sitnikov.vladimir@gmail.com, PostgreSQL-development References: <20200528.181139.1631626601933187948.horikyota.ntt@gmail.com> <20200529072138.GG44192@paquier.xyz> <20200529.175653.1322451159722162490.horikyota.ntt@gmail.com> <20200602042456.GA3594@paquier.xyz> From: Fujii Masao Message-ID: Date: Tue, 2 Jun 2020 14:23:50 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200602042456.GA3594@paquier.xyz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/06/02 13:24, Michael Paquier wrote: > On Fri, May 29, 2020 at 06:09:06PM +0900, Masahiko Sawada wrote: >> Yes. Conversely, if we start logical replication in a physical >> replication connection (i.g. replication=true) we got an error before >> staring replication: >> >> ERROR: logical decoding requires a database connection >> >> I think we can prevent that SEGV in a similar way. > > Still unconvinced as this restriction stands for logical decoding > requiring a database connection but it is not necessarily true now as > physical replication has less restrictions than a logical one. Could you tell me what the benefit for supporting physical replication on logical rep connection is? If it's only for "undocumented" backward-compatibility, IMO it's better to reject such "tricky" set up. But if there are some use cases for that, I'm ok to support that. > Looking at the code, I think that there is some confusion with the > fake WAL reader used as base reference in InitWalSender() where we > assume that it could only be used in the context of a non-database WAL > sender. However, this initialization happens when the WAL sender > connection is initialized, and what I think this misses is that we > should try to initialize a WAL reader when actually going through a > START_REPLICATION command. > > I can note as well that StartLogicalReplication() moves in this sense > by setting xlogreader to be the one from logical_decoding_ctx once the > decoding context has been created. > > This results in the attached. The extra test from upthread to check > that logical decoding is not allowed in a non-database WAL sender is a > good idea, so I have kept it. Yes. Also we should add the test to check if physical replication can work fine even on logical rep connection? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION