Dear Amit,
> I understand that we may not have a clear use case for this to work in
> single-user mode. But how will we define the boundary in similar
> cases? I mean, we should have some rule for such exposed functions,
> and it should be followed uniformly. Now, if one needs a bigger or
> comple
On Thu, Feb 27, 2025 at 1:29 PM Hayato Kuroda (Fujitsu)
wrote:
>
> >
> > 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)
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
Ch
On Thu, Feb 20, 2025 at 6:21 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear hackers,
>
> Thanks everyone for giving comments! PSA new version.
> What's new:
>
> - Message format was modified to {"cannot use function %s in single-user
> mode", "function_name"}
> - Reporting funcname was adjusted based
Dear hackers,
Thanks everyone for giving comments! PSA new version.
What's new:
- Message format was modified to {"cannot use function %s in single-user mode",
"function_name"}
- Reporting funcname was adjusted based on the parameters. ternary operator was
used.
- Guard was added for functions
Dear Amit,
> Also, what about pg_replication_origin_* APIs? Do we want to restrict
> those as well if we are restricting slot operations? I don't see any
> solid theory presented in this thread on why we should add new checks
> in multiple APIs restricting those in single-user mode.
As David [1]
On Thu, Feb 20, 2025 at 4:26 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, February 20, 2025 10:23 AM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear Michael,
> >
> > > I did not check how these call behave individually, just a few
> > > comments while putting my eyes on the patch.
> > >
> > > +
On Thursday, February 20, 2025 10:23 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Michael,
>
> > I did not check how these call behave individually, just a few
> > comments while putting my eyes on the patch.
> >
> > + if (!IsUnderPostmaster)
> > + elog(ERROR,
> > +
Hi,
On Thu, Feb 20, 2025 at 02:22:41AM +, Hayato Kuroda (Fujitsu) wrote:
> Dear Michael,
>
Thanks for the report and the patch!
> > I did not check how these call behave individually, just a few
> > comments while putting my eyes on the patch.
> >
> > + if (!IsUnderPostmaster)
> > +
On Wed, Feb 19, 2025 at 7:23 PM Hayato Kuroda (Fujitsu) <
kuroda.hay...@fujitsu.com> wrote:
> I intentionally used elog() because I thought single user mode is not
> user-facing.
> But it is OK for me to use ereport() instead.
>
Single-user mode is also known as "Oh crap!" mode, something used wh
Dear Michael,
> I did not check how these call behave individually, just a few
> comments while putting my eyes on the patch.
>
> + if (!IsUnderPostmaster)
> + elog(ERROR,
> + "slot operation is prohibited in the single user
> mode");
>
> elog() should not b
On Wed, Feb 19, 2025 at 02:57:34AM +, Hayato Kuroda (Fujitsu) wrote:
> Based on the discussion, I feel it is enough to add quick error out
> for SQL functions. PSA attached.
I did not check how these call behave individually, just a few
comments while putting my eyes on the patch.
+ if
el Paquier'
> Cc: 'pgsql-hackers@lists.postgresql.org'
> Subject: RE: ReplicationSlotRelease() crashes when the instance is in the
> single
> user mode
>
> Dear Michael,
>
> > Ah, good point for the slot drop. So 0ce5cf2ef24f is claiming that
> &g
Dear Michael,
> Ah, good point for the slot drop. So 0ce5cf2ef24f is claiming that
> some of these manipulations are OK. I didn't suspect this one.
Yeah, I think so.
> Slot advancing is a very different beast, unfortunately, that may
> depend on many other subsystems. For example with logical
On Tue, Feb 18, 2025 at 07:29:51AM +, Hayato Kuroda (Fujitsu) wrote:
> According to the original thread [1], there was a wide consensus
> replication-related
> operations can be rejected, except the slot removal. I feel this is
> reasonable.
>
> Currently pg_drop_replication_slot() requires
Dear Michael,
> Perhaps a very naive question, but is there any point in authorizing
> manipulations of MyReplicationSlot in single-user mode, to begin with?
> With this remark, I would mean to apply a rule to
> ReplicationSlotAcquire(), so as all its callers would know about that.
According to t
On Monday, February 17, 2025, Hayato Kuroda (Fujitsu) <
kuroda.hay...@fujitsu.com> wrote:
>
> backend> SELECT pg_create_physical_replication_slot(slot_name :=
> 'physical_slot', immediately_reserve := true);
Since this function releases the slot when it returns, re-acquisition, even
by the same
On Tue, Feb 18, 2025 at 05:33:05AM +, Hayato Kuroda (Fujitsu) wrote:
> I found $SUBJECT when I'm playing with the single user mode.
Perhaps a very naive question, but is there any point in authorizing
manipulations of MyReplicationSlot in single-user mode, to begin with?
With this remark, I wo
18 matches
Mail list logo
