RE: [Patch] add new parameter to pg_replication_origin_session_setup

Dear Amit, Shveta,

> > >
> > > Thanks Hou-San and Kuroda-San.
> > >
> > > What should be the expected behavior when Session1 resets the origin
> > > (changing acquired_pid from its own PID to 0), while Session2 is
> > > already connected to the origin and Session3 also attempts to reuse
> > > the same origin?
> > >
> > > Currently it asserts:
> > >
> > > Session1:
> > > select pg_replication_origin_create('origin');
> > > SELECT pg_replication_origin_session_setup('origin');
> > >
> > > Session2:
> > > SELECT pg_replication_origin_session_setup('origin',48028);
> > >
> > > Session1:
> > > SELECT pg_replication_origin_session_reset();
> > >
> > > Session3:
> > > SELECT pg_replication_origin_session_setup('origin');
> > > This asserts at:
> > > TRAP: failed Assert("session_replication_state->refcount == 0"), File:
> > > "origin.c", Line: 1231, PID: 48037
> > >

FYI, this happened because v1 assumed refcount was 0 if acquired_by was 0.
But your proposed scenario met it.

> > I checked the behavior on HEAD. Session3 is able to set up the origin
> > and sets its own PID in acquired_pid. But it is unclear to me which
> > PID should be recorded in acquired_pid - Session2’s PID, since it set
> > up the origin earlier, or Session3’s PID. Or does this even make any
> > difference?

To clarify, I think the behavior on HEAD is not correct. The backend should
acquire the active origin if it expressly specifies the PID. Otherwise, users
may acquire unintentionally and advance it.

> Can we address these problems by prohibiting leader worker to reset
> when pa workers are still associated with the origin? The way for
> leader to know if pa workers are associated with origin is by checking
> following condition: acquired_by == MyProcpid AND refcount > 1.

I think it's okay. IIUC, the idea is to avoid that active origin has invalid
acquired_by attribute. The replication origin was extended to support parallel
apply of logical replication, and it is reasonable to force the same approach.
Attached 0001 implemented that.

One concern with the implementation is that acquired_by can be zero if the process
exits without releasing the origin; this can happen if the first acquired process
exits while the second is still using it.
Regarding our logical replication, it won't be problematic because the leader
worker ensures all parallel workers finish before it exits.

To address the issue, I propose that another process should not be able to
acquire the origin if the acquired_by of the active origin is 0. The problem
should be resolved within the SQL interface, since it occurs there.

Best regards,
Hayato Kuroda
FUJITSU LIMITED