Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Michael Paquier <michael@paquier.xyz>,
Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, sitnikov.vladimir@gmail.com,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-06-02T05:23:50Z
Lists: pgsql-hackers
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix crash in WAL sender when starting physical replication
- 10ffe0fa72ed 13.0 landed
- 879ad9f90e83 14.0 landed
-
Add a SHOW command to the replication command language.
- d1ecd539477f 10.0 cited