On Tue, Dec 2, 2025 at 6:41 PM Bernd Helmle <[email protected]> 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
