row_security
Read PG 18 manual ↗This variable controls whether to raise an error in lieu of applying a row security policy.
- Type
- bool
- Context
- user
- Measured default
- on
- Unit
- —
- Metadata snapshot
- 18
Definition PG 18 manual
This variable controls whether to raise an error in lieu of applying a row security policy. When set to on, policies apply normally. When set to off, queries fail which would otherwise apply at least one policy. The default is on. Change to off where limited row visibility could cause incorrect results; for example, pg_dump makes that change by default. This variable has no effect on roles which bypass every row security policy, to wit, superusers and roles with the BYPASSRLS attribute.
For more information on row security policies, see CREATE POLICY.
Measured default history
| Version interval | Default |
|---|---|
| 9.5 – 19 | on |
Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗
How it works
row_security enables row security. When enabled, row security will be applied to all users. Off does not bypass policies for ordinary roles: it raises an error where a policy would apply, which lets tools such as pg_dump avoid silently incomplete results.
row_security is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.
Because session state can survive in pooled connections, role defaults, SET privilege, RESET behavior, and application checkout hooks are part of the control's effective boundary.
Operational considerations
Changing row_security in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
Granting broad SET rights to a control that can change correctness, policy enforcement, or name resolution.
Failing to reset a security-sensitive session value before a pooled connection is reused by another request.
Setting off expecting a bypass, although ordinary roles receive an error when a policy would apply.
Workload guidance
OLAP: Use a dedicated analytical role if row_security must differ, and verify that exports, triggers, policies, and name resolution still preserve data correctness.
OLTP: Treat row_security as a correctness or security control, not a throughput knob. Grant SET authority narrowly and establish it from trusted role or application policy.
SMALL: Keep row_security at its safe default unless a documented repair or compatibility workflow requires otherwise; record and automatically restore temporary changes.
Version history 3
- PG 17 → 18changed
- PG 10 → 11changed
- PG 9.4 → 9.5added
Related entries
Further reading
Definition snapshot: english-manuals:0c835b6e69a444f6a72b35790dd… · English manual source