Horton
Menu

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

Dave Cramer <davecramer@postgres.rocks>

View thread
From: Dave Cramer <davecramer@postgres.rocks>
To: Michael Paquier <michael@paquier.xyz>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Vladimir Sitnikov <sitnikov.vladimir@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-06-03T11:33:14Z
Lists: 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.

Dave Cramer
https://www.postgres.rocks

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix crash in WAL sender when starting physical replication

  2. Add a SHOW command to the replication command language.