On Tue, Apr 29, 2025 at 02:01:54PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandboss...@gmail.com> writes:
>> Thanks.  I'll stash this away for July unless someone wants to argue that
>> it's fair game for v18.  IMHO this isn't nearly urgent enough for that, and
>> the bugs will continue to exist on older major versions regardless.
> 
> I'm inclined to argue that it's a bug fix and therefore still in-scope
> for v18.  The fact that we can't back-patch such a change is all the
> more reason to not let it slide another year.  But probably the RMT
> should make the call.

Tomas, Heikki: Thoughts on removing pg_replication_origin's TOAST table
post-feature-freeze?  The proposed commit message explains what's going on:

        A few places that access this catalog do not set up an active
        snapshot before potentially accessing its TOAST table, which is
        unsafe.  However, roname (the replication origin name) is the only
        varlena column, so this is only ever a problem if the name requires
        out-of-line storage, which seems unlikely.  This commit removes its
        TOAST table to avoid needing to set up a snapshot, and it
        establishes a length restriction of 512 bytes for replication
        origin names.  Even without this restriction, names that would
        require out-of-line storage would fail with a "row is too big"
        error; the additional length restriction just provides a more
        specific error message.

-- 
nathan


Reply via email to