On Wed, Apr 5, 2023 at 9:27 PM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: > > On 4/5/23 3:15 PM, Amit Kapila wrote: > > On Wed, Apr 5, 2023 at 6:14 PM Drouvot, Bertrand > > <bertranddrouvot...@gmail.com> wrote: > >> > >> On 4/5/23 12:28 PM, Amit Kapila wrote: > >>> On Wed, Apr 5, 2023 at 2:41 PM Drouvot, Bertrand > >>> <bertranddrouvot...@gmail.com> wrote: > >> > >>> minor nitpick: > >>> + > >>> + /* Intentional fall through to session cancel */ > >>> + /* FALLTHROUGH */ > >>> > >>> Do we need to repeat fall through twice in different ways? > >>> > >> > >> Do you mean, you'd prefer what was done in v52/0002? > >> > > > > No, I was thinking that instead of two comments, we need one here. > > But, now thinking about it, do we really need to fall through in this > > case, if so why? Shouldn't this case be handled after > > PROCSIG_RECOVERY_CONFLICT_DATABASE? > > > > Indeed, thanks! Done in V61 posted up-thread. >
After this, I think for backends that have active slots, it would simply cancel the current query. Will that be sufficient? Because we want the backend process should exit and release the slot so that the startup process can mark it invalid. For walsender, an ERROR will lead to its exit, so that is fine. If this understanding is correct, then if 'am_cascading_walsender' is false, we should set ProcDiePending apart from other parameters. Sorry, I haven't tested this, so I could be wrong here. Also, it seems you have removed the checks related to slots, is it because PROCSIG_RECOVERY_CONFLICT_LOGICALSLOT is only used for logical slots? If so, do you think an Assert would make sense? Another comment on 0001. extern void CheckSlotRequirements(void); extern void CheckSlotPermissions(void); +extern void ResolveRecoveryConflictWithLogicalSlots(Oid dboid, TransactionId xid, char *reason); This doesn't seem to be called from anywhere. -- With Regards, Amit Kapila.
