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

On 2020/06/03 20:33, Dave Cramer wrote:
>
>
>
> On Wed, 3 Jun 2020 at 01:19, Michael Paquier <michael(at)paquier(dot)xyz <mailto:michael(at)paquier(dot)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.

For the back branches, I agree with you. Even if it's undocumented behavior,
basically we should not get rid of it from the back branches unless there is
very special reason.

For v13, if it has no functional merit, I don't think it's so bad to get rid of
that undocumented (and maybe not-fully tested) behavior. If there are
applications depending it, I think that they can be updated.

> 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.

+1

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION