RE: ReplicationSlotRelease() crashes when the instance is in the single user mode

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Amit Kapila' <amit.kapila16@gmail.com>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Michael Paquier <michael@paquier.xyz>, "David G. Johnston" <david.g.johnston@gmail.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Date: 2025-02-27T07:58:40Z
Lists: pgsql-hackers

Attachments

Dear Amit,

> Shouldn't such a check be present in the CheckSlotPermissions() kind
> of function to perform it in the central place?

OK. I checked whether we can reuse pre-existing functions, but it seems not appropriate.
CheckSlotPermissions() is called even by pg_drop_replication_slot(), and
CheckSlotRequirements() is not called by pg_sync_replication_slots(). I defined new
function CheckSlotIsInSingleUserMode() and put the check there.
I removed function name from the ereport(), but I feel it is enough - CheckSlotPermissions()
and CheckSlotRequirements() do not have.

> > For now, functions for replication origin and replication messages were
> retained.
> > I can handle them after the discussion.
> >
> 
> Which other functions do we see similar restrictions? I checked
> "sequence manipulation functions" (1), and "Transaction ID and
> Snapshot Information Functions" (2) but couldn't see similar
> restrictions.
> 
> (1) - https://www.postgresql.org/docs/current/functions-sequence.html
> (2) -
> https://www.postgresql.org/docs/current/functions-info.html#FUNCTIONS-INF
> O-SNAPSHOT

I grepped sources and could not find explicit limitations neither. So...this might
be overkill. But I still think the restriction is OK for the slot - no need to do
some efforts for accepting single-user mode, just close the cover.

Best regards,
Hayato Kuroda
FUJITSU LIMITED

Commits

  1. Fix assertion failure with replication slot release in single-user mode