createrole_self_grant

createrole_self_grant is the PostgreSQL setting that defines whether a CREATEROLE user automatically grants the role to themselves, and with which options.

Note

Fact — official short description: “Sets whether a CREATEROLE user automatically grants the role to themselves, and with which options.”

Identity

Type , Valuestring: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueClient Connection Defaults / Statement Behavior: Upstream classification
Latest boot value , Value"": empty string

Lifecycle

Fact	Value
First observed	PG16
Present in	PG16–19 Beta 3
Removed in	No
Introduction commit	`e5b8a4c098ad` — Add new GUC createrole_self_grant.
Commit date	2023-01-10
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG16–19 Beta 3	`""`	—	empty string

How it works

createrole_self_grant sets whether a CREATEROLE user automatically grants the role to themselves, and with which options. An empty string disables automatic self grants. The accepted options are set, inherit, or both; it automates a grant the creating CREATEROLE user could issue with ADMIN OPTION and does not affect superusers.

createrole_self_grant 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.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	Treat createrole_self_grant as a correctness or security control, not a throughput knob. Grant SET authority narrowly and establish it from trusted role or application policy.
OLAP	Use a dedicated analytical role if createrole_self_grant must differ, and verify that exports, triggers, policies, and name resolution still preserve data correctness.
Small nodes	Keep createrole_self_grant at its safe default unless a documented repair or compatibility workflow requires otherwise; record and automatically restore temporary changes.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG16–19 Beta 3 unmodified; OLAP: PG16–19 Beta 3 unmodified; CRIT: PG16–19 Beta 3 unmodified; TINY: PG16–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Changing createrole_self_grant 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.
Changing createrole_self_grant globally without a rollback plan and a client or operational compatibility test.

search_path · row_security · session_replication_role · event_triggers · restrict_nonsystem_relation_kind