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...
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?
Bernd
