PG 17 and GUC variables

Started by Bruce Momjianabout 2 years ago5 messageshackers
Beta feature

Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.

appliessuccessCI history

You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:

docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t49830
psql -h localhost -U postgres

Built from patchset v5 (message #5), August 25, 2026 at 08:46 AM.

Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:

git clone --branch t49830_5 https://github.com/hackorum-dev/postgres.git

In a checkout you already have, add the fork once:

git remote add hackorum https://github.com/hackorum-dev/postgres.git

then, for this patchset and every later one:

git fetch hackorum t49830_5 && git checkout t49830_5

Patchset v5 (message #5) is on t49830_5

Jump to latest
#1Bruce Momjian
bruce@momjian.us

FYI, looking at the release notes, I see 15 GUC variables added in this
release, and two removed. That 15 number seemed unusually high so I
thought I would report it.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

#2Michael Paquier
michael@paquier.xyz
In reply to: Bruce Momjian (#1)
Re: PG 17 and GUC variables

On Thu, Jun 20, 2024 at 08:01:19PM -0400, Bruce Momjian wrote:

FYI, looking at the release notes, I see 15 GUC variables added in this
release, and two removed. That 15 number seemed unusually high so I
thought I would report it.

Scanning pg_settings across the two versions, I'm seeing:
- Removed GUCs between 16 and 17:
db_user_namespace
old_snapshot_threshold
trace_recovery_messages

- Added GUCs between 16 and 17:
allow_alter_system
commit_timestamp_buffers
enable_group_by_reordering
event_triggers
huge_pages_status
io_combine_limit
max_notify_queue_pages
multixact_member_buffers
multixact_offset_buffers
notify_buffers
serializable_buffers
standby_slot_names
subtransaction_buffers
summarize_wal
sync_replication_slots
trace_connection_negotiation
transaction_buffers
transaction_timeout
wal_summary_keep_time

So that makes for 3 removed, 19 additions and a +16.
--
Michael

#3Robert Treat
xzilla@users.sourceforge.net
In reply to: Michael Paquier (#2)
Re: PG 17 and GUC variables

On Thu, Jun 20, 2024 at 10:03 PM Michael Paquier <michael@paquier.xyz> wrote:

On Thu, Jun 20, 2024 at 08:01:19PM -0400, Bruce Momjian wrote:

FYI, looking at the release notes, I see 15 GUC variables added in this
release, and two removed. That 15 number seemed unusually high so I
thought I would report it.

Scanning pg_settings across the two versions, I'm seeing:
- Removed GUCs between 16 and 17:
db_user_namespace
old_snapshot_threshold
trace_recovery_messages

- Added GUCs between 16 and 17:
allow_alter_system
commit_timestamp_buffers
enable_group_by_reordering
event_triggers
huge_pages_status
io_combine_limit
max_notify_queue_pages
multixact_member_buffers
multixact_offset_buffers
notify_buffers
serializable_buffers
standby_slot_names
subtransaction_buffers
summarize_wal
sync_replication_slots
trace_connection_negotiation
transaction_buffers
transaction_timeout
wal_summary_keep_time

I was looking at trace_connection_negotiation and ran across this
commit removing it's mention from the release notes because it is
undocumented: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=95cabf542f04b634303f899600ea62fb256a08c2

Why is the right solution to remove it from the release notes rather
than to document it properly? It's not like people won't notice a new
GUC has popped up in their configs. Also, presumaing I'm unerstanding
it's purpose correctly, ISTM it would fit along side other trace_*
gucs in https://www.postgresql.org/docs/current/runtime-config-developer.html#RUNTIME-CONFIG-DEVELOPER.

Robert Treat
https://xzilla.net

#4Heikki Linnakangas
heikki.linnakangas@enterprisedb.com
In reply to: Robert Treat (#3)
Re: PG 17 and GUC variables

On 04/08/2024 06:29, Robert Treat wrote:

I was looking at trace_connection_negotiation and ran across this
commit removing it's mention from the release notes because it is
undocumented: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=95cabf542f04b634303f899600ea62fb256a08c2

Why is the right solution to remove it from the release notes rather
than to document it properly? It's not like people won't notice a new
GUC has popped up in their configs. Also, presumaing I'm unerstanding
it's purpose correctly, ISTM it would fit along side other trace_*
gucs in https://www.postgresql.org/docs/current/runtime-config-developer.html#RUNTIME-CONFIG-DEVELOPER.

Not sure whether it's worth mentioning in release notes, but I think
you're right that it should be listed in that docs section. How about
the attached description?

I see that there are two more developer-only GUCs that are not listed in
the docs:

trace_syncscan
optimize_bounded_sort

There's a comment on them that says "/* this is undocumented because not
exposed in a standard build */", but that seems like a weak reason,
given that many of the other options in that docs section also require
additional build-time options. I think we should add those to the docs
too for the sake of completeness.

--
Heikki Linnakangas
Neon (https://neon.tech)

Attachments:

document-trace_connection_negotiation.patchtext/x-patch; charset=UTF-8; name=document-trace_connection_negotiation.patchDownload+20-0
#5Robert Treat
xzilla@users.sourceforge.net
In reply to: Heikki Linnakangas (#4)
Re: PG 17 and GUC variables

On Sun, Aug 4, 2024 at 4:45 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:

On 04/08/2024 06:29, Robert Treat wrote:

I was looking at trace_connection_negotiation and ran across this
commit removing it's mention from the release notes because it is
undocumented: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=95cabf542f04b634303f899600ea62fb256a08c2

Why is the right solution to remove it from the release notes rather
than to document it properly? It's not like people won't notice a new
GUC has popped up in their configs. Also, presumaing I'm unerstanding
it's purpose correctly, ISTM it would fit along side other trace_*
gucs in https://www.postgresql.org/docs/current/runtime-config-developer.html#RUNTIME-CONFIG-DEVELOPER.

Not sure whether it's worth mentioning in release notes, but I think
you're right that it should be listed in that docs section. How about
the attached description?

Slightly modified version attached which I think is a little more succinct.

I see that there are two more developer-only GUCs that are not listed in
the docs:

trace_syncscan
optimize_bounded_sort

There's a comment on them that says "/* this is undocumented because not
exposed in a standard build */", but that seems like a weak reason,
given that many of the other options in that docs section also require
additional build-time options. I think we should add those to the docs
too for the sake of completeness.

Agreed.

Robert Treat
https://xzilla.net

Attachments:

t49830_5
document-trace_connection_negotiation-2.patchapplication/octet-stream; name=document-trace_connection_negotiation-2.patchDownload+20-0