On 2020/06/17 3:50, Alvaro Herrera wrote:
On 2020-Jun-17, Fujii Masao wrote:

While reading InvalidateObsoleteReplicationSlots() code, I found another issue.

                        ereport(LOG,
                                        (errmsg("terminating walsender %d because replication 
slot \"%s\" is too far behind",
                                                        wspid, 
NameStr(slotname))));
                        (void) kill(wspid, SIGTERM);

wspid indicates the PID of process using the slot. That process can be
a backend, for example, executing pg_replication_slot_advance().
So "walsender" in the above log message is not always correct.

Good point.

So InvalidateObsoleteReplicationSlots() can terminate normal backends.
But do we want to do this? If we want, we should add the note about this
case into the docs? Otherwise the users would be surprised at termination
of backends by max_slot_wal_keep_size. I guess that it's basically rarely
happen, though.


                        int                     wspid = 
ReplicationSlotAcquire(NameStr(slotname),
                                                                                
                           SAB_Inquire);

Why do we need to call ReplicationSlotAcquire() here and mark the slot as
used by the checkpointer? Isn't it enough to check directly the slot's
active_pid, instead?

Maybe ReplicationSlotAcquire() is necessary because
ReplicationSlotRelease() is called later? If so, why do we need to call
ReplicationSlotRelease()? ISTM that we don't need to do that if the slot's
active_pid is zero. No?

I think the point here was that in order to modify the slot you have to
acquire it -- it's not valid to modify a slot you don't own.

Understood. Thanks!


+               /*
+                * Signal to terminate the process using the replication slot.
+                *
+                * Try to signal every 100ms until it succeeds.
+                */
+               if (!killed && kill(active_pid, SIGTERM) == 0)
+                       killed = true;
+               ConditionVariableTimedSleep(&slot->active_cv, 100,
+                                                                       
WAIT_EVENT_REPLICATION_SLOT_DROP);
+       } while (ReplicationSlotIsActive(slot, NULL));

Note that here you're signalling only once and then sleeping many times
in increments of 100ms -- you're not signalling every 100ms as the
comment claims -- unless the signal fails, but you don't really expect
that.  On the contrary, I'd claim that the logic is reversed: if the
signal fails, *then* you should stop signalling.

You mean; in this code path, signaling fails only when the target process
disappears just before signaling. So if it fails, slot->active_pid is
expected to become 0 even without signaling more. Right?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION


Reply via email to