lolor

Overview

works on pgedge kernel fork. Requires lolor.node

Version

Build

You can build the RPM / DEB packages for lolor using pig build:

pig build pkg lolor         # build RPM / DEB packages

Install

You can install lolor directly. First, make sure the PGDG and PIGSTY repositories are added and enabled:

pig repo add pgsql -u          # Add repo and update cache

Install the extension using pig or apt/yum/dnf:

pig install lolor;          # Install for current active PG version

pig ext install -y lolor -v 18  # PG 18
pig ext install -y lolor -v 17  # PG 17
pig ext install -y lolor -v 16  # PG 16
pig ext install -y lolor -v 15  # PG 15

dnf install -y pgedge-18       # PG 18
dnf install -y pgedge-17       # PG 17
dnf install -y pgedge-16       # PG 16
dnf install -y pgedge-15       # PG 15

apt install -y pgedge-18   # PG 18
apt install -y pgedge-17   # PG 17
apt install -y pgedge-16   # PG 16
apt install -y pgedge-15   # PG 15

Create Extension:

CREATE EXTENSION lolor;

Usage

Sources:

• v1.2.2 README
• Control file
• Version 1.2.2 migration
• Usage reference
• Release notes lolor 1.2.2 stores large-object chunks and metadata in ordinary tables so logical replication can include them. Enabling it replaces the database’s native large-object routines; it is a database-wide behavior change, not an independent object store.

Configure and Enable

Assign each writing node a distinct nonzero lolor.node before creating large objects. Upstream documents values from 1 through 2^28. Configure the server’s parameter and create the extension in each participating database:

lolor.node = 1

CREATE EXTENSION lolor;
SET search_path = lolor, "$user", public, pg_catalog;

The control file fixes schema lolor, declares trusted installation and disallows relocation. The upstream README requires PostgreSQL 16 or newer; the current Pigsty pgEdge bundle has separately tested builds for 15–18. That packaging result does not establish support for arbitrary stock PostgreSQL 15 installations.

Large Object Workflow

WITH created AS (
  SELECT lo_from_bytea(0, convert_to('example data', 'UTF8')) AS oid
)
SELECT oid, convert_from(lo_get(oid), 'UTF8') AS contents FROM created;

Standard calls such as lo_create(), lo_get(), lo_put() and lo_unlink() use the replacement routines. Descriptor-based access through lo_open(), loread(), lowrite() and lo_close() must stay within the same transaction. File import/export operates on server-side paths and remains subject to the relevant function and filesystem privileges.

The extension uses lolor.pg_largeobject and lolor.pg_largeobject_metadata. Existing catalog routines are retained with renamed originals so disabling or removing the extension can restore the native function names.

Replication

With a configured Spock replication set, include both tables:

SELECT spock.repset_add_table('default', 'lolor.pg_largeobject');
SELECT spock.repset_add_table('default', 'lolor.pg_largeobject_metadata');

Install compatible versions and coordinate node identifiers and object ownership on every node. Creating the extension alone does not create a logical-replication topology.

Upgrade and Boundaries

Version 1.2.2 repairs extension and major-version upgrade behavior and adds lolor.disable(), lolor.enable() and lolor.is_enabled(). Update lolor before running pg_upgrade; the fix does not retroactively repair a major upgrade already attempted with older extension files:

ALTER EXTENSION lolor UPDATE TO '1.2.2';
SELECT lolor.is_enabled();

Disabling changes which native function names are active; it does not migrate stored large objects. Native large-object migration is not provided. Native large-object functionality and lolor storage cannot be used interchangeably while lolor is enabled. Upstream excludes ALTER LARGE OBJECT, GRANT ON LARGE OBJECT, COMMENT ON LARGE OBJECT and REVOKE ON LARGE OBJECT. Plan backup, restore and replication for both ordinary tables.