Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762
Дата
Msg-id CADK3HHLWWHUpFZp1XAj3b4hTxZVUyaVJeooePck=UbQhPXTgQA@mail.gmail.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  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-hackers



On Wed, 3 Jun 2020 at 01:19, Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Jun 02, 2020 at 02:23:50PM +0900, Fujii Masao wrote:
> On 2020/06/02 13:24, Michael Paquier wrote:
>> 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.

Well, I don't really think that we can just break a behavior that
exists since 9.4 as you could break applications relying on the
existing behavior, and that's also the point of Vladimir upthread.

I don't see this is a valid reason to keep doing something. If it is broken then fix it.
Clients can deal with the change. 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Следующее
От: Ants Aasma
Дата:
Сообщение: Re: what can go in root.crt ?