Skip to content

lolor Release Notes

lolor 1.3.0

  • Add bidirectional large object migration between native PostgreSQL and lolor storage, implemented as a direct relation-to-relation copy in C (lolor.migrate_storage()) rather than a loop through the large object API:
  • lolor.migrate_from_native(peer_oids oid[] DEFAULT NULL) moves native large objects into lolor storage. It is a manual step after CREATE EXTENSION lolor, requires superuser, and returns the number of objects moved or -1 if the migration was refused.
  • lolor.migrate_to_native() moves them back, whether or not lolor is enabled. It is a manual step before dropping the extension; the drop is refused while any object remains in lolor storage and no longer migrates anything itself.
  • Both directions preserve OIDs, owners, ACLs, comments and the exact page layout, so sparse objects stay sparse. Ownership and ACLs are recorded in pg_shdepend on the way back, so DROP ROLE, REASSIGN OWNED and DROP OWNED see the objects again. Comments are parked in lolor.pg_largeobject_description while an object is in lolor storage. Native objects are removed with the same bookkeeping as DROP (dependencies, comments and labels), but without the per-object locks DROP takes, so a database with more large objects than the lock table can hold is migrated without raising max_locks_per_transaction.
  • Storage layouts are verified against the running server at migration time. Security labels, which lolor storage cannot represent, cause migrate_from_native() to refuse. OID conflicts are reported with the conflicting OIDs.
  • Migration holds ShareRowExclusiveLock on both stores until commit. Ordinary large object access takes RowExclusiveLock, which does not conflict with itself, so a concurrent lo_write() could otherwise be lost silently. Opposing migrations take their locks in a fixed order and cannot deadlock.
  • Both migration functions refuse while any other session is connected to the database, and refuse to run from anything but a client session.
  • With spock installed, both functions run under spock.repair_mode(). If a logical slot spock cannot suppress exists, a non-spock slot or any slot when spock is absent, they refuse rather than let subscribers decode the migration as row changes.
  • Migration is node-local: native large objects are never replicated, so run the migration on each node by connecting to it directly. Do not send it through DDL replication, which would run it inside every subscriber's apply worker. Native OIDs are not node-encoded, so pass the other nodes' OIDs (from lolor.native_lo_oids()) as peer_oids to turn a cross-node collision into a refusal, and compare lolor.digest() across nodes afterwards.
  • migrate_to_native() refuses with a clear error while any object refers to a dropped role, instead of failing part-way with "role N was concurrently dropped"; remove those objects with lo_unlink() and retry.
  • New helpers lolor.digest() and lolor.native_lo_oids() for cross-node checks after a node-local migration.
  • New helpers lolor.check_orphans() and lolor.fix_orphans(new_owner) for objects whose owner, grantee or grantor has been dropped. Objects in lolor storage cannot participate in pg_shdepend, so DROP ROLE does not notice them; check_orphans() lists them and which reference is dangling, and fix_orphans() reassigns dead owners, replacing them in the ACL as REASSIGN OWNED would so that grants they made survive, and drops entries that still name a missing role.
  • Security fix: lo_import() and lo_export() were executable by any database user. These read and write files on the server as the account PostgreSQL runs under, so core revokes EXECUTE on them from PUBLIC. lolor replaces them by renaming the originals to *_orig; an ACL belongs to a function rather than a name, so the restriction stayed on the parked original while each replacement got the default EXECUTE TO PUBLIC. Any user could read an arbitrary server file with lo_import() or overwrite one with lo_export(). The replacements are now locked down at install time, and upgrading revokes the privilege on existing installations in either state. Versions 1.0 through 1.2.2 are affected.
  • The extension is no longer marked trusted. Installing lolor renames functions in pg_catalog for the whole database, which a non-superuser should not be able to do.
  • Fixed DROP ROLE failing with "unrecognized object class". Creating a large object recorded a pg_shdepend row whose classId was the OID of lolor.pg_largeobject, an ordinary table rather than a catalog. Any role that had created a large object became undroppable, and the rows were never cleaned up because inv_drop() deleted with PERFORM_DELETION_SKIP_ORIGINAL. lolor no longer records these rows, and the upgrade removes the ones already present.
  • The cleanup is per database, so ALTER EXTENSION lolor UPDATE must be run in every database that has lolor. Until it is, DROP ROLE anywhere in the cluster keeps reporting "owner of objects in database X".
  • A database that ran DROP EXTENSION lolor on an earlier version still has the rows, now pointing at a table that no longer exists, and no upgrade script will run there. Clean it by hand as superuser in that database: find the stale class OIDs with SELECT DISTINCT classid FROM pg_shdepend WHERE dbid = (SELECT oid FROM pg_database WHERE datname = current_database()) AND classid NOT IN (SELECT oid FROM pg_class), then DELETE FROM pg_shdepend WHERE dbid = <that dbid> AND classid IN (<those OIDs>).
  • lolor must now be listed in shared_preload_libraries. Loading it on demand is refused: CREATE EXTENSION lolor, LOAD 'lolor' and any call that reaches one of lolor's functions fail with lolor must be loaded via "shared_preload_libraries"; the native pg_catalog.lo_* functions are not affected while lolor is not installed or is disabled. The drop guard below is an object access hook, which is only present in every backend and worker when the library is preloaded, and a missing or broken library now fails at server start rather than at the first lo_open(). Upgrade in this order: install the new library files, add lolor to shared_preload_libraries, restart, then run ALTER EXTENSION lolor UPDATE in each database. Between the file install and the restart, any session that loads the new library on demand gets that error, so restart promptly.
  • Removing the extension is guarded by an object access hook. DROP EXTENSION, DROP SCHEMA lolor CASCADE, DROP OWNED BY and any other path that reaches the extension are refused while lolor is enabled or while any object remains in lolor storage, checked in the catalog at the moment of deletion from whichever backend performs it. The drop no longer migrates the objects out itself: run lolor.migrate_to_native() first. The event trigger only puts the native pg_catalog.lo_* names back. The new superuser setting lolor.allow_unsafe_drop skips both checks and discards the contents of lolor storage. Because the drop renames the native functions back, it has the same requirements as lolor.disable(): no other session connected to the database, and a client session.
  • lolor.enable() and lolor.disable() refuse to run from anything but a client session, so replicated DDL cannot execute them inside an apply worker, where a refusal would leave that node's replication retrying forever.
  • lolor.enable(), lolor.disable() and lolor.is_enabled() now probe exact function signatures in pg_catalog. They previously matched on proname across every schema, so any user with CREATE on any schema could define a function named lolor_lo_open and wedge lolor into a permanent "inconsistent state" that also blocked DROP EXTENSION. Both now emit a notice that client sessions must reconnect, since libpq caches the large object function OIDs per connection, and refuse while any other session is connected to the database, since a renamed function keeps its OID and other sessions cannot be made to see the switch.
  • Fixed the lolor.node upper bound. The GUC accepted 0..16 while a generated OID reserves four bits for the node id, so node 16 did not fit: the node field of every OID it generated read back as 0. The bound is now derived from the encoding (LOLOR_MAX_NODE_ID), giving 0..15. If you have lolor.node = 16 configured, the server still starts but logs 16 is outside the valid range for parameter "lolor.node" (0 .. 15) and falls back to 0, which is the node id it was effectively using already. Set it to a value in 0..15, and check for OID collisions against whichever node is genuinely 0.
  • Expanded test coverage: TAP tests for dump/restore, streaming and logical replication, standby promotion, the drop paths, migration fidelity and locking, and cross-node OID collisions; regression tests for lo_lseek, lo_tell, lo_truncate, the 64-bit interface, sparse objects, comment round trips, pg_shdepend restoration, permission enforcement, the orphan helpers and name squatting. The regression suite runs on its own preloaded instance.
  • Security hardening: addressed Codacy/Flawfinder warnings.

lolor 1.2.3

  • Add support for PostgreSQL 19
  • Add in-repo release workflow and RPM/DEB packaging
  • Improve CI: build the test cluster from source, add PostgreSQL 19 to the test matrix, and bound test run time

lolor 1.2.2

  • Fix lolor upgrades
  • Fix issues with pg_upgrade. Note that this fixes upgrades with pg_upgrade going forward. ALTER EXTENSION UPDATE for upgrading the extension itself works, so if wanting to run pg_upgrade, first update your extension to 1.2.2, then run pg_upgrade
  • Address CVEs CVE-2022-26520, GHSA-673j-qm5f-xpv8
  • PATH updated to match native Postgres packaging layout
  • Make table OID caching safer