Re: Proposal: Support Logical replication of large objects

On Tue, Dec 2, 2025 at 6:41 PM Bernd Helmle <mailings(at)oopsware(dot)de> wrote:
>
> Am Montag, dem 01.12.2025 um 09:27 +0530 schrieb Dilip Kumar:
> > The decoder will then translate the standard single-row
> > insert/update WAL records generated for the internal pg_largeobject
> > table rows into logical operations formatted as LOWRITE: OID, OFFSET,
> > DATA, LENGTH, where the OFFSET is calculated as pageno (corresponding
> > to pg_largeobject row) * LOBLKSIZE. Subsequently, the apply worker on
> > the subscriber side converts this logical operation into lo_open(),
> > lo_seek() and lowrite() operation. While there is potential for
> > further optimization by generating the LOWRITE operation only for the
> > modified data instead of for the entire LOBLKSIZE bytes this behavior
> > is consistent with how updates are currently logged for standard user
> > tables.
>
>
> Thanks for this, i think this is a long awaited feature, at least for
> those workloads that can't easily get rid of LOs...

Right

> I didn't look into your POC (yet), but what happens if the subscriber
> database concurrently does lo_create()? Would that cause conflicting
> OIDs, preventing applying the records decoded from the publisher?

I've implemented decoding for lowrite operations, specifically
handling INSERT statements into pg_largeobject by translating them
into corresponding lowrite operations. However, lo_create is currently
not decoded. The patch expects the user to execute lo_create on the
subscriber explicitly, similar to how DDL for tables is handled.

But I understand the lo_create can be a very frequent activity so
instead of treating them as DDL we should decode and replicate the
lo_create as well and I have asked for the suggestion in my email.
And if we replicate the lo_create as well then any existing
conflicting OID on the subscriber will create conflict and I believe
we can handle that as part of conflict detection.

--
Regards,
Dilip Kumar
Google