On Thu, 28 May 2020 at 05:11, Kyotaro Horiguchi <horikyota....@gmail.com> wrote:
> Hello, Vladimir. > > At Thu, 28 May 2020 11:57:23 +0300, Vladimir Sitnikov < > sitnikov.vladi...@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
