Re: Proposal: Support Logical replication of large objects

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: Support Logical replication of large objects
Date: 2025-12-02 13:06:06
Message-ID: 448faab512d6da9bb8678ba895b0d68dafe2f979.camel@oopsware.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-12-02 13:07:47 Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
Previous Message Zsolt Parragi 2025-12-02 13:05:49 Custom oauth validator options