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

On Thu, 28 May 2020 at 05:11, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
wrote:

> Hello, Vladimir.
>
> At Thu, 28 May 2020 11:57:23 +0300, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote in
> > Kyotaro>It seems to me that that crash means Pgjdbc is initiating a
> logical
> > Kyotaro>replication connection to start physical replication.
> >
> > Well, it used to work previously, so it might be a breaking change from
> the
> > client/application point of view.
>
> Mmm. It is not the proper way to use physical replication and it's
> totally accidental that that worked (or even it might be a bug). The
> documentation is saying as the follows, as more-or-less the same for
> all versions since 9.4.
>
> https://www.postgresql.org/docs/13/protocol-replication.html
>
> > To initiate streaming replication, the frontend sends the replication
> > parameter in the startup message. A Boolean value of true (or on, yes,
> > 1) tells the backend to go into physical replication walsender mode,
> > wherein a small set of replication commands, shown below, can be
> > issued instead of SQL statements.
> >
> > Passing database as the value for the replication parameter instructs
> > the backend to go into logical replication walsender mode, connecting
> > to the database specified in the dbname parameter. In logical
> > replication walsender mode, the replication commands shown below as
> > well as normal SQL commands can be issued.
>
> regards.
>
> While the documentation does indeed say that there is quite a bit of
additional confusion added by:

and
START_REPLICATION [ SLOT *slot_name* ] [ PHYSICAL ] *XXX/XXX* [ TIMELINE
*tli* ]

If we already have a physical replication slot according to the startup
message why do we need to specify it in the START REPLICATION message ?

Dave