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

On Thu, 4 Jun 2020 at 19:46, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> On 2020-Jun-04, Andres Freund wrote:
>
> > postgres[52656][1]=# SELECT 1;
> > ┌──────────┐
> > │ ?column? │
> > ├──────────┤
> > │ 1 │
> > └──────────┘
> > (1 row)
> >
> >
> > I am very much not in love with the way that was implemented, but it's
> > there, and it's used as far as I know (cf tablesync.c).
>
> Ouch ... so they made IDENT in the replication grammar be a trigger to
> enter the regular grammar. Crazy. No way to put those worms back in
> the tin now, I guess.
>

Is that documented ?

>
> It is still my opinion that we should prohibit a logical replication
> connection from being used to do physical replication. Horiguchi-san,
> Sawada-san and Masao-san are all of the same opinion. Dave Cramer (of
> the JDBC team) is not opposed to the change -- he says they're just
> using it because they didn't realize they should be doing differently.

I think my exact words were

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

in response to:

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

Which is different than not being opposed to the change. I don't see this
as broken,
and it's quite possible that some of our users are using it. It certainly
needs to be documented

Dave