Re: Proposal: Support Logical replication of large objects
Bernd Helmle <mailings@oopsware.de>
From: Bernd Helmle <mailings@oopsware.de>
To: Dilip Kumar <dilipbalaut@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-02T13:06:06Z
Lists: pgsql-hackers
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