In PostgreSQL releases prior to 9.0, large objects did not have access privileges and were, therefore, always readable and writable by all users.
At a glance
| Property | Value |
|---|---|
| Parameter | lo_compat_privileges |
| Category | Version and Platform Compatibility |
| Default | off |
| Value type | boolean (on/off) |
| Change scope | Per-session (SET) |
| Available in | PostgreSQL 12, 13, 14, 15, 16, 17, 18, 19 (added in 12) |
What it does
In PostgreSQL releases prior to 9.0, large objects did not have access privileges and were, therefore, always readable and writable by all users. Setting this variable to on disables the new privilege checks, for compatibility with prior releases. The default is off. Only superusers and users with the appropriate SET privilege can change this setting.
Setting this variable does not disable all security checks related to large objects — only those for which the default behavior has changed in PostgreSQL 9.0.
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Can be set per session with SET, per role/database with ALTER ROLE/DATABASE ... SET, or globally in postgresql.conf.
Inspect the current value and source with SHOW lo_compat_privileges; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'lo_compat_privileges';.
Tuning guidance
This controls backward-compatibility behaviour, not performance. Keep it at the modern default unless a specific legacy application depends on the older behaviour; turning compatibility flags on to paper over application bugs stores up problems for a future upgrade. Treat any non-default value as technical debt to remove.