From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, sitnikov(dot)vladimir(at)gmail(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 |
Date: | 2020-06-03 21:44:48 |
Message-ID: | 20200603214448.GA901@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-Jun-02, Michael Paquier wrote:
> 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.
I don't particularly disagree with your proposed patch -- in fact, it
seems to make things cleaner. It is a little wasteful, but I don't
really mind that. It's just some memory, and it's not a significant
amount.
That said, I would *also* apply Kyotaro's proposed patch to prohibit a
physical standby running with a logical slot, if only because that
reduces the number of combinations that we need to test and keep our
collective heads straight about. Just reject the weird case and have
one type of slot for each type of replication. I didn't even think this
was at all possible.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-06-03 22:08:16 | Re: question regarding copyData containers |
Previous Message | Thomas Munro | 2020-06-03 21:40:31 | Re: Atomic operations within spinlocks |