Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762
От | Fujii Masao |
---|---|
Тема | Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762 |
Дата | |
Msg-id | b7b1fcaa-2532-a1e9-6533-d74954608003@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762 (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762
Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762 |
Список | 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
В списке pgsql-hackers по дате отправления: