| 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
| 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 |