Rewrite large object migration as a direct relation copy.

[ibrarahmad]

lolor moves large objects between PostgreSQL's native storage and its own tables with lolor.migrate_from_native() and lolor.migrate_to_native(). The move back to native storage is written in plpgsql and rebuilds each object through the large object API, one lo_lseek64() and one lowrite() call per 2 KB page, because the original commit believed rows cannot be inserted into pg_catalog.pg_largeobject directly. A superuser can insert into it, and both functions already require superuser.

A 1 GB large object is about 500,000 pages, so moving it back costs about a million function calls. A sparse object, with data at offset 0 and at offset 10 MB and nothing in between, occupies two pages, but the move writes all 5,000 pages in between as zeros, so 4 KB of data becomes 10 MB on disk.

After migrate_to_native(), DROP ROLE alice succeeds although alice still owns the migrated objects, and REASSIGN OWNED BY alice TO bob leaves them untouched. Ownership was set with a plain UPDATE on the catalog, which records nothing in pg_shdepend, the table PostgreSQL uses to protect owned objects.

COMMENT ON LARGE OBJECT 16385 IS 'invoice scan', then migrate_from_native(), then migrate_to_native(): the comment is gone.

While a migration runs, another session's lo_write() can commit between the copy of the rows and the removal of the originals, and that write disappears with no error. Both sides take RowExclusiveLock, which does not conflict with itself.

Native large object OIDs are not node encoded. Running migrate_from_native() on several nodes of a cluster can map different objects onto the same OID, and because the migration runs under spock.repair_mode(), the other nodes never see it happen.

How this PR fixes it

lolor.migrate_storage(to_native boolean), in C, copies tuples directly between pg_catalog.pg_largeobject{,_metadata} and lolor.pg_largeobject{,_metadata}. The two pairs have the same layout by construction, and the function compares the tuple descriptors against the running server before copying anything. Pages are copied as they are, so a sparse object stays sparse and no per-page API calls are made. Native objects are removed with performMultipleDeletions(), the path DROP uses, so their dependencies, comments and security labels go with them. Each row is processed in its own memory context. migrate_to_native() no longer requires lolor to be enabled, and DROP EXTENSION lolor still migrates objects back through the existing event trigger, now through this copy.

On the way to native storage, ownership and ACLs are recorded with recordDependencyOnOwner() and recordDependencyOnNewAcl(), so DROP ROLE, REASSIGN OWNED and DROP OWNED see the objects again.

Comments are kept in a new table, lolor.pg_largeobject_description, while an object is in lolor storage and put back with CreateComments() when it returns. lo_unlink() removes the parked row so a reused OID cannot pick it up.

Both stores are locked with ShareRowExclusiveLock until the transaction commits, in a fixed order so that two migrations in opposite directions cannot deadlock.

Before copying to native storage, every owner and every role in an ACL is checked against pg_authid; objects that refer to a dropped role are reported with their OIDs and the migration refuses, with a hint to lo_unlink() them, instead of failing part way through with role N was concurrently dropped. Both functions refuse while another session is connected to the database and when run from anything other than a client session. migrate_from_native(peer_oids oid[]) refuses if any native OID on this node is in the list, and lolor.native_lo_oids() and lolor.digest() produce the per-node data for building that list and comparing nodes afterwards. migrate_from_native() also refuses if any large object carries a security label, which lolor storage cannot represent.

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{This review includes 12 billable files and costs up to $3.00.}

Or wait 59 minutes for your next included review.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 380ce27e-b5d6-4fbb-8a7f-dd9c535bc377

---

📥 Commits

Reviewing files that changed from the base of the PR and between 6d7cc89 and 11a814f.

---

⛔ Files ignored due to path filters (1)

• expected/lolor.out is excluded by !**/*.out

---

📒 Files selected for processing (12)

• Makefile
• README.md
• docs/index.md
• docs/lolor_release_notes.md
• lolor--1.2.2--1.3.0.sql
• sql/lolor.sql
• src/lolor.c
• src/lolor.h
• src/lolor_largeobject.c
• src/lolor_migrate.c
• t/009_migration.pl
• t/010_migration_locking.pl

---

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}

[codacy-production]

Up to standards ✅

🟢 Issues 16 high · 5 medium

Results:
21 new issues

Category	Results
Compatibility	16 high (4 false positives)
Complexity	5 medium

View in Codacy

🟢 Metrics 68 complexity · 2 duplication

Metric	Results
Complexity	68
Duplication	2

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}