Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762
От | Michael Paquier |
---|---|
Тема | Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762 |
Дата | |
Msg-id | 20200602042456.GA3594@paquier.xyz обсуждение исходный текст |
Ответ на | Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762 (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
Ответы |
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 Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762 |
Список | pgsql-hackers |
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. 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. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: