PostgreSQL wiki - User contributions [en]

PGConf.dev 2026 Developer Unconference

2026-06-09T12:17:06Z

Petere: /* What Other Optimizer Stats Do We Want */

The unconference at [[PGConf.dev 2026]] will be organized by Andres Freund and Nathan Bossart. Please add notes about individual sessions here! You can either include them in the body of the page, or put them on another page and link from here.

'''If you feel that your session cannot be productive without a particular conference attendee present, please ask their permission to include them as a "required attendee" for your proposal. The organizers will use this information to minimize scheduling conflicts.'''

----

== Postgres and Other Communities ==

So many ideas and suggestions on the notes page! [https://wiki.postgresql.org/wiki/PGConf.dev_2026_Developer_Unconference/Postgres_and_other_communities]

----

== Global Index ==

We want global indexes, because:

* Allows unique constraints on non-partition keys.
* Scan on one index is cheaper than N scans on N indexes

3 problems:

1. VACUUM: 1000s of partitions each must run cleanup on the same index relation; which is sized to 1000s of partitions' data.
2. DDL: Adding & removing partitions requires maintenance on the global index.  How to decide whether rebuild from scratch or to apply changes with only the new/removed tuples
3. Locking: Scanning the global index still requires locks on all leaf tables that contribute(d) to that index. Scanning a table requires having a lock on the relation. Scanning the index itself doesn't require locking, but you'll still have to lock the leaf partitions to access their data.
1. There are schemes to make this work, using multi-pass operations

Room:
4. Sizing: Individual relations are limited to 32TB, and that doesn't scale with ; is this something we want/need to solve, too?

----

Q: What's the main blocker? Is this a good idea?

A: Primarily: VACUUM.

----

Q1: Is the solution to VACUUM conveyor belt (mentioned yesterday)

A: No, instead of vacuuming that partition, all partitions are VACUUMed at once, gathering the TIDs that the global index will clean up.

Q2: What's the status of the conveyor belt?

A: Hit a snag on planning VACUUM operations and [...]
Response: Serializing VACUUM of a partition hierarchy is likely going to cause issues; VACUUM interrupts become incredibly much more expensive.

----

Comment: DDL is likely the most pressing issue. Conveyor belt may fix VACUUM, but DDL isn't trivial either.

DDL Attach: 2-phase attach with first xact adding the partition as 'invalid', then load tuples into index, then second xact marking the partition valid.

----

Q: Does sub-partitioning affect partition ID usage?

A: No, only leaf partitions (data partitions) are included in the IDs

----

Comment: Maybe we should disallow certain operations when global indexes are involved.

Response: Yes, that seems like a reasonable limitation

Q: Which operations would be disallowed?

A: On-the-fly locking of partitions accessed through a global index scan would break with leaf table insertion, so in this case we should block leaf partition -level DML.

Comment: The main customer for Global Indexes are people coming in from Oracle, which doesn't allow direct leaf access

----

Comment: Even with 10s of 1000s of attached partitions you still win, because it'll have only few key bytes, not full rows.

----

Q: What other avenues were explored to achieve global index's features, without this current approach [single relfile index, ed.]

A: There was a Global Unique Index approach, which had unique indexes per partition, and checked other partitions' unique indexes for conflicting values.

----

Comment: We need to scope it down to make it through.

Q: How does DROP PARTITION work with Global Index?

A: The partition ID is marked invalid, and all tuples that reference this ID will be dropped during maintenance operations.

----

Q1: What needs to change in indexAM? 

A: minimal changes to indexes themselves.

Q2: And REPACK/VACUUM FULL?

A: Just rebuild the index on REPACK/VACUUM FULL.

----

Q: Performance. What's the overhead for locking in Index Scans vs Global Index Scans?

A: IS needs to scan each index, vs GIS only the global index. The number of locks is unchanged (unless runtime on-access locking is applied)

== Commit Sequence Numbers ==

(Incomplete notes by mmeent)

There are several implementations. Jeff (organizer) wants to talk about changes in visibility semantics that we need to discuss and agree on.

First, PG has different visibility semantics on Primary vs replica (causes "Long Fork" anomaly):

* Replica visibility is determined by LSN/replay order.
* Primary visibility order is determined by persistence window, and prock lock ordering.

With CNS we have an opportunity to allow readers to determine the visibility interpretation of the system: record created vs record flushed vs record replicated.

Comment: May cause problems with hint bits

Q: Are we considering CSN for Long Fork, or are we considering CSN for faster snapshots? They don't strictly need to be combined.

A: [...]

----

Comment: Combining both is likely to make the patch unnecessarily complicated.

----

Q: Please clarify; do you expect CSNs to be in lockstep with LSNs?

A: From an implementation perspective this could be done, but isn't probable.

A: If we define visibility semantics to be

Comment: If the visibility order doesn't match WAL order we'll have to get another system.

Andres: "We could also just decide we'll continue to suck." ... The best approach would be to have quorum flush, but that'd require proper node registration, and that has too many dependencies.

----

The current system has many levels of durability and that causes differences.

Q: When should sync_commit=off vs =on release for visibility?

A: Thought is: =off returns to the client once inserted. To maintain semantics the read-path would have "visible=inserted in wal". If you'd wait for persistence you'd lose performance.

----

Comment: We can't have sessions' sync_commit settings affect visibility semantics. "That way lies madness."

Comment: The covered behaviour is that sync returns after flush, async returns before WAL flush. If CSN visibility is determined by XLOG flush location, that'll cause issues with async commits; as it would either have to wait for a sync, or might not be able to read its own writes.

----

Suggestion: If you (a session in sync commit mode) want to see async commits, wait for the async commit is synced (or issue the sync yourself).

----

Comment: We should agree on anomalies like "async sessions sees something == sync session sees that (or later) data"

Comment: The problem is that durability is decoupled from visibility; LSN order <> visibility order with mixed sync_commit=off|local|remote_write|remote_apply.

----

Q: Do we want sync commits to see async commits? 

A: Sync commits wait for async-but-visible commits to be synced, then read their data.

Q: Do we want async commits to see sync commits?

A: [...]

----

There were some questions about how CSNs in a logical replication context would relate to MySQL's GTIDs. CSNs themselves (as currently proposed, with a 64-bit counter) wouldn't provide an equivalent to GTID. A global transaction order would need to be managed by an external program.

== Scaling pg_stat_statements ==

[[Scalability of pg_stat_statements]]

== Feedback-based Query Optimization ==

[[pgconfdev2026 Feedback-based Query Optimization]]

== Postgres CI ==

[https://docs.google.com/presentation/d/1O-QtTaeajoTbO6epDTQoGnafld3LVvk8rkdD9yAUsUg/edit?slide=id.g3e9d54500dd_0_0#slide=id.g3e9d54500dd_0_0 Bilal's Slides]
[https://www.postgresql.org/message-id/flat/DIM49A100EY1.2YFS2A6WAI3ZJ%40jeltef.nl#845813013b1995cc81b850761a989b4f Mailing list thread]

* Cirrus CI will shut down June 1st
* We need to find another CI provider
* Bilal has done some tests using GitHub Actions as a CI runner
* Jelte independently has done tests on GitHub Actions as well

Problems we want to solve:
* Runtime
* Compute limitations
* Public logs (Cirrus CI had public logs, everyone can read them)
* Connecting to a test environment
* Supporting different operating systems

CFBot will be broken in any case

Looked at a couple of alternatives [[CI Providers]]

* GitHub Actions is good because unlimited for public repositories
* 20 concurrent jobs for GitHub Actions (might be able to get that lifted)
* Could also host our own runners if we need to

What is a runner in this context?

* Its a VM in some environment that starts the test
* We did that with Cirrus already, but it has some level of isolation between runs
* The basic infrastructure in GitHub has no isolation, which is a problem
* Would have to preprovision VMs to make that work, would need more compute

Peter: Ran into a problem with using up credits in Cirrus CI

* This is much better with GitHub Actions (credits don't run out)

Thomas: Jelte's test got all operating systems going, did that use nested virtualization?

* Yes, that was running nested containers, that's why OpenBSD takes 34 minutes
* If that's what was done, could we use that on our local machines?
* That'd be the dream if we could do that
* Andres: The problem is that you can't just download them every time, its a lot of network I/O
* With Cirrus CI it just downloaded the part of the image it needed, that's why that worked
* To do that efficiently we'd need our own CI infrastructure

Peter: There are a bunch of other projects that use CirrusCI that are in trouble (e.g. pgbouncer)

* Let's keep in mind what the other projects could do

It would be interesting to check how well the current disk image compresses

Andres: We should consider skipping BSDs initially for expediency (regarding the deadline of June 1st)

Peter: We have one week - should we at least provisionally go with GitHub Actions?

* Andres: Yes
* Then come back to looking at alternatives
* Peter G: I already thought that's what we're going to do - I don't see any reason not do that

Most important things are Linux, Windows, MacOS, Compiler Warnings/ASAN

* Thomas: If macOS compiles, the BSDs are going to compile and run

Michael: Windows has been super helpful

Peter G: Don't we use FreeBSD for some other checks, debug parallel query, etc?

* The official FreeBSD website has 600MB VM images, might be small enough?
* Andres: Unclear how much the dependencies add?

With Cirrus you can use your own images, with GitHub you can't

Its very recent that you can use QEMU on GitHub (nested virtualization wasn't allowed previously, it is now)

David: Sent a link in Discord re: action using BSD

Peter G: So we have a patch right?

* Yes
* Runtimes are a bit longer compared to Cirrus CI, but not too much
* Windows 20-25 minutes on GitHub Actions, Cirrus CI was faster mostly (15-25 minutes)
* Andres: I want to commit this early next week, so we have some days of overlap
* Its also going to make it easier to move CFbot over

Can you show how logs / file uploads look like?

* Similar, but for artifacts you need to download a zip file
* Need a GitHub account to view the logs, will accept that for now

David: Do we care about ARM64/etc?

* Andres: We care about 32-bit builds, that will catch some bugs
* Bilal: That's done (32-bit)

Should we have some helper scripts in addition to GitHub actions?

* Might be better to have in one place?
* Andres: Motivation for helper scripts would be that it'd make it easier to share code between platforms
* Peter E: Could run it locally to test things

Andres: I'd want to backpatch this, wanted to check

* Thomas: Agreed
* Peter E: Down to 14?
* Andres: 15, we don't have 14 at the moment in Cirrus
* Windows would be painful to do on 14
* Michael: Seems the cost is too high given the fact we're only 6 months out from PG14 being EOL

What coverage are we going for (just check world?)

* Same as Cirrus basically, just won't be able to do the BSDs initially

Thomas: To feed the results from GH actions into CFbot, not clear how to do it

* Bilal: Was already planning to look into it
* Thomas: Will probably turn off the stuff that examines the logs
* Andres: Might have to call back into GitHub and use a token to not get rate limited

Peter E: There is logic in the commitfest app when CI is failing, need to check how that interacts

* Thomas: The way it works is that Cirrus sends a status change to a web hook, and CFbot feeds that into the CF app
* Only the CFbot needs to be changed
* If you make this work in regular GitHub accounts, it will also work for CFbot

Debian vs Ubuntu

* Debian requires containers, Ubuntu does not
* Peter E: Should be fine to do Ubuntu
* Andres: Should check if we can use our containers without too much overhead
* Peter E: Where do you host the containers?
* Andres: Currently in Google, should probably move them to make it cheaper (somewhere to GitHub)

Peter E: What compiler is the Windows job using?

* Bilal: MSVC 2022
* Peter E: How can we get 2019 tested?
* Tristan: You can specify it using the matrix (and its part of the image)

Andres: Lets just remove MSVC 2019 support
* Thomas: I don't know why we do it, its already unsupported officially by Microsoft
* Peter E: I was cautious because not sure how Windows users use their system, but maybe with Windows the coupling is not as tight
* Andres: They actually removed installers for specific MSVC compiler versions after 2019 (its one link, the next time you rebuild the image it gets a newer one)

For Windows, the GitHub Actions images have more things installed
* Bilal: We might not have to build Windows images anymore (and not hardcode OpenSSL version)
* Andres: One problem with Chocolatey is that they have broken binaries, also sometimes a lot slower
* Pavlo: WinGet?
* Andres: Doesn't have several packages we need

Connecting to test environment
* Not currently out of the box in GitHub Actions, possibly via a third-party SSH action?
* Is that solved by GitHub Workspace?
* Someone could try that out

----

== How to do HA with Physical Replication ==

=== HA Orchestrators (physical repl) ===

Patroni, Stolon, pg_auto_failover, repmgr, CloudNativePG, Consul?

=== Promotions/Transitions and Correctness ===

* Cluster config changes: <code>sync_standby_names</code>, <code>sync_commit</code>
* SyncRep waits in commit (canceled xact issue, etc.)
* Knowing write/flush/replay LSNs
* Old primary: <code>pg_rewind</code> and accepting workload after conversion to replica
* Any issues around timeline management?
** Latest timeline — issues reconstructing from history file

==== Discussion Notes ====

'''Andrey:''' Should we have cluster orchestration like Patroni in core?

* '''Laurenze:''' PG is supported on many OS & platforms — needs to work everywhere
* HA is an enterprise requirement — table stakes
* '''Philippe:''' Want to control tradeoffs around availability vs. durability; have worked systems with debates around how tradeoffs should be made. Correctness is a high priority; maybe some people want to relax this
* '''Mohamed:''' It's possible to make tradeoffs configurable — maximizing durability, performance, availability (example from Oracle Data Guard)
* '''Laurenze:''' Maybe we have too much configuration? Can set <code>synchronous_commit</code> at transaction level

Is the discussion around automated failover almost a discussion around consensus?

The way you do fencing can vary depending on what hardware or infrastructure you're running on:
* Can you fence with network? Do you have access to hardware?

Are there ways protocol changes could make these problems easier to solve?

'''Jeremy:''' Does <code>synchronous_commit=remote_write</code> mean you can lose data? (Probably not?)
* Do we KNOW if it happened or not?

We need to be able to explain tradeoffs to people.

'''Oleksii:''' Would be nice to see something like <code>pg_ctl demote</code>:
* Aware of replicas — say to primary "demote" — primary waits for replicas
* Part of switchover: block incoming connections, wait for replication; goes hand-in-hand (before) <code>pg_promote</code>
* Sentinel record in WAL stream saying primary is definitely down

==== More Discussion Notes ====

for switchover ubicloud relies on https://github.com/ubicloud/ubicloud/blob/main/rhizome/postgres/lib/postgres_lockout.rb

on aws EIP based failover was fast enough that after lockout it was sufficient to just go with usual failover path on switchover
on azure, where I got to maintain port of Citus Cloud, failover was slow (poweroff could be hanging because vm host down, in which case next step was destroy vm which could take 10 minutes), so for switchover I implemented "soft failover" which would trash the system with chmod -x while killing postgres processes, allowing us to act as if it was fenced

.

promoting a node when it's time to promote a node, we have nothing to do this in core. patroni in core?

would be nice, but portability. maintenance burden? what is HA? HA vs durability

oracle makes this adjustable (maximize availability vs maximize durability vs maximum performance), patroni has this too apparently

postgres has too many knobs already: durability knobs per transaction. semantics here are unclear. (this was reviving previous commit sequence number discussion)

goal is to not lose transactions. flushlsn/replaylsn/receievelsn how does ANY 2 replication choose what to promote to?

how do you prepare for promote? change to read only? fence? failover vs switchover. fencing mechanism differs by environment, is inherently tribal (some rely on undocumented AWS behavior with EIP, azure you need to poweroff/terminate/destroy vm)

when people own their own hardware, they might rely on actual reboot/poweroff of node. Quorum can get around this a bit by being able to maintain consistency without fencing

what data loss guarantees do we have? can we at least know that data loss didn't happen usually?

extreme end: no accepting new wal until quorum regained

=== Replication Slot Management ===

* Logical slot HA (<code>failover=true</code> on standby)

logical slot failover slots have problems where you have to use physical slots & if slot isn't advancing that can block switchover. wal slot grows indefinitely if using pg_logical_emit_message non-transactionally on system with no transactions

if slot not advancing impacts vacuum etc. maintenance script needs to generate activity

Right now there's the issue that you need physical slots. You have slot sync running on the side; logical slots don't copy until there's activity:
* Maintenance — can't fail back because there wasn't activity to advance slot
* Not good quality of life
* Running systems can have keepalive or background activity
* If slot is not advancing, there are bigger issues
* There should be background activity that causes slots to advance

=== Standby Topics ===

* Hot standby feedback and bloat
* Autovac truncation

=== Missing First Principles ===

what is an overarching idea to help this situation? ALTER SYSTEM READ ONLY. standby-quorum fencing. or protocol where primary cooperates independently in split-brain scenarios (needs way for primary to know this is happening)

<code>ALTER SYSTEM READ ONLY</code>?
* For switchover — ability to make primary read-only

Not really any cluster awareness in Postgres?
* Writer has: <code>sync_standby_names</code>, <code>replication_status</code>
* Standby does not know

standby doesn't know what's going on in rest of cluster, just what wal it receives. pg_nodes? replicated sync_standby_names (but need name mapping)?

Global table? <code>pg_nodes</code> or something?

Should value of <code>sync_standby_names</code> be replicated? Need <code>primary_conninfo</code> too.

Could standbys agree a primary is unavailable?

== What Other Optimizer Stats Do We Want ==

Out of scope:
* join statistics (separate topic)
* adaptive statistics as the query is running (previous session)

Ideas:
* (Peter E.) statistics about what is in memory (replaces effective_cache_size, use mincore (portability?))
** might get obsolete with AIO
* collect stats in streaming (incremental) way, for large tables there is a 3 mio. row limit
** nr. of buckets, sample size is currently coupled
** dynamic sampling (like in Oracle?)
** disable sampling
* (David R.) getting statistics from indexes has been problematic
** might be better via extension points
* JOB (Join Order Benchmark) 2x better with more complete statistics
* cardinality hints might be coming
* risk-based costing, cardinality distributions
** DR: model cost of one extra row
* Corey: store multiple versions of stats (like MS SQL Server)
** use it for triggering random sampling
* special statistics for string operations (LIKE '%foo%')
* (Maxime) statistics for aggregates output
* (Feike) statistics on system (to inform cost parameters)
** DR: we do not model enough (e.g. tuple deforming)
** F: systems go through cycles, wants to adjust by time of day
* ML-based tuning
* Corey: percentage of toasted columns (makes hash tables more expensive, order of predicate processing)
** column width
** function cost could scale with datum width

PGConf.dev 2026 Developer Unconference

2026-06-09T10:51:49Z

Petere: add new section

PGConf.dev 2026 Translators and Translation Tooling

2026-05-06T11:58:43Z

Petere: /* Discussion topics */

https://www.pgevents.ca/events/pgconfdev2026/schedule/session/543-translators-and-translation-tooling/

= Planning =

Please add yourself below if you plan to attend in person or remotely. This is not required, but it will help the organizers. (In particular, if no one signs up for remote attendance, there will be no remote link.) Remote attendees, please take note of the time that this session is scheduled for.

== Plan to attend in person ==

* Peter Eisentraut (organizer)
* Jonathan Gonzalez V.
* Pavlo Golub
* Euler Taveira
* Grant Zhou
* ...

== Plan to attend remotely ==

* ...

== Discussion topics ==

Add topic proposals here:

* External translation tools, e.g. CrowdIn, Lokalise, Phrase, Transifex, etc.
* AI agents to help with translations (models, skills, workflows, ..)
* source code management: libpgport, libpgcommon handling, adding new files
* finishing meson support
* tooling or code changes to reduce need for manual checking, for example vertical alignment of --help output
* ...

[[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2026 In-Person Commitfest

2026-05-04T20:20:36Z

Petere:

https://www.pgevents.ca/events/pgconfdev2026/schedule/session/578-special-pgconfdev-in-person-commitfest/

The special PGConf.dev in-person commitfest runs during the week of
[[PGConf.dev 2026]]. Patches are registered and reviewers are assigned ahead
of the conference. Patch authors and reviewers meet during the
conference week as individually agreed to discuss the patches and if
appropriate move them closer to "Ready for Committer" status.

This gives all interested patch authors an opportunity to meet with
and learn from experienced developers in person, and it can help
facilitate moving some development projects forward in anticipation of
the next PostgreSQL development cycle.

------

Current: The list of patches in play can be found via these two links:

* https://commitfest.postgresql.org/59/?tag=44 (commitfest PG20-1)
* https://commitfest.postgresql.org/60/?tag=44 (commitfest PG20-Drafts)

------

The information and rules below are meant to give participants and
organizers some guidelines for how to operate this event, but they are
not meant to be in the way of having an enjoyable and productive
event. If there is something beyond what is discussed here, check
with the organizers and/or give it a try. The main goal is to learn
together.

= How to participate =

Every conference attendee can participate. You participate by
submitting a patch (see below) or signing up to review a patch. No
further signup beyond that exists.

= Submitting a patch / Signing up to review =

This event will be run on top of the PostgreSQL [[Commitfest]] system.
Patches should be submitted to either commitfest [https://commitfest.postgresql.org/59/ PG20-1] or [https://commitfest.postgresql.org/60/ PG20-Drafts]
and tagged with the tag "[https://commitfest.postgresql.org/?tag=44 PGConf.dev]".

Reviewers who want to participate look for patches with the tag and
sign up as reviewer.

<strike>Note: When you add the tag to an existing entry, you should remove all
existing reviewers. (Because we can't assume that those reviewers
will be at the conference or will participate in this.) The
commitfest managers will do this if necessary. If necessary, one can
add the previous reviewers back afterwards.</strike> (Edit: This requires CF admin privileges, so the commifest managers will do it.)

= Timeline =

* Signups are possible now (as of 10 April).

* Patches should be registered by 4 May at the latest (2 weeks before the conference). Later arrivals might not give reviewers enough time to prepare.

* Reviewers/committers sign up and prepare during those 2 weeks.

* Patch authors and reviewers meet during the week to discuss (perhaps more than once).

* We might present a summary or some statistics at the end of the conference week.

= Some rules =

* Obviously, both patch authors and reviewers must attend the conference.

* Maximum 2 patches per author (Consider the second one a backup if genuinely no one is available with expertise to review the first one.)

* More than one author or more than one reviewer is okay, but please coordinate this. The more people are involved, the harder it will be to find a time to meet.

* Everyone should sign up for themselves and as themselves. If you want to bring your team of co-authors or colleagues to the meeting, you should disclose this and request consent. Do not ambush your pairing partner with unexpected guests.

* Patches should be interesting enough to facilitate a conversation and learning experience. Patches that are trivial or mostly mechanical or that you do not understand yourself or that have already been thoroughly reviewed are not conducive.

* We are generally looking for two kinds of review pairings:
** Committer reviews patch by returning contributor. (It is assumed that the contributor generally knows their way around. The committer can help move the patch to completion.)
** Experienced developer reviews patch by new-ish contributor. (Here, the focus could be more on initial review and familiarization with process expectations, as well as getting to know.)
** (As a counterexample, it is normally useful for a new contributor to review a patch by an experienced contributor for oversights, usability, portability, etc., but this is probably not appropriate for this in-person event.)

The commitfest managers may reach out to involved parties or make adjustments of registered patches to facilitate this.

* Patches may be in need of either technical review or process guidance (or both). Use tags in the commitfest app judiciously to indicate your needs.

* The conference [https://2026.pgconf.dev/about/code-of-conduct code of conduct] applies.

* The event begins when the conference begins and ends when the conference ends. You are encouraged to keep working beyond that, of course, but that will be outside the scope of this event.

= The process before and during the conference =

* Patches should be in "Needs review" state before reviewer signup begins.

* Patches should pass Cirrus CI. (Unless this is the subject of the review, in which case use additional tags indicating this.)

* <strike>When adding the "PGConf.dev" tag, clear out existing reviewer entries.</strike>

* Reviewers study the patch ahead of the conference.

* Patch authors and reviewers meet during the conference to discuss feedback and decide on next steps.

* To find each other in person, if you don't know each other, in general, patch authors should reach out to reviewers to establish communication channels and arrange meetings (rather than the other way around). This will likely work better because you will have a better chance getting help at the conference locating a well-known committer than locating a first-time conference attendee or similar.

* Many experienced contributors will be very busy on Tuesday (community discussions) and Friday (unconference), so the best days to meet are probably Wednesday and Thursday. But you should already try to make contact before that.

* Room "Xerox" (Room 1500) is available for these meetings. (There will be a few other meetings in this room, but it is mostly free.) You can meet anywhere else, of course, but this should be the most comfortable. Note that this is not reserved for individual pairings, please share appropriately.

* Don't forget to post a review on pgsql-hackers, or at least a note that you met and discussed the patch, to keep everyone else in the loop.

* Set patch status to "Waiting on author" or "Ready for committer" as appropriate. This is at least to have some fun stats for this event at the end of the week.

= Communicating =

* The organizer of this event (that is, the commitfest manager) is Peter Eisentraut <peter@eisentraut.org>. Contact him with questions.

* The information desk at the conference might be a good place to get help finding rooms and people.

* The conference Discord server is the place to connect with attendees, find your review partners, etc.

* The [https://2026.pgconf.dev/about conference organizers] can be contacted for higher-level questions.

* There is a conference [https://2026.pgconf.dev/about/code-of-conduct code of conduct committee].

* The PostgreSQL Hacking Discord server and the pgsql-hackers mailing list should be used for discussing issues related to the technical contents of a patch.

* This wiki page may be updated from time to time with emerging generally useful information.

[[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2026 In-Person Commitfest

2026-05-04T19:57:33Z

Petere:

https://www.pgevents.ca/events/pgconfdev2026/schedule/session/578-special-pgconfdev-in-person-commitfest/

The special PGConf.dev in-person commitfest runs during the week of
[[PGConf.dev 2026]]. Patches are registered and reviewers are assigned ahead
of the conference. Patch authors and reviewers meet during the
conference week as individually agreed to discuss the patches and if
appropriate move them closer to "Ready for Committer" status.

This gives all interested patch authors an opportunity to meet with
and learn from experienced developers in person, and it can help
facilitate moving some development projects forward in anticipation of
the next PostgreSQL development cycle.

------

The information and rules below are meant to give participants and
organizers some guidelines for how to operate this event, but they are
not meant to be in the way of having an enjoyable and productive
event. If there is something beyond what is discussed here, check
with the organizers and/or give it a try. The main goal is to learn
together.

= How to participate =

Every conference attendee can participate. You participate by
submitting a patch (see below) or signing up to review a patch. No
further signup beyond that exists.

= Submitting a patch / Signing up to review =

This event will be run on top of the PostgreSQL [[Commitfest]] system.
Patches should be submitted to either commitfest [https://commitfest.postgresql.org/59/ PG20-1] or [https://commitfest.postgresql.org/60/ PG20-Drafts]
and tagged with the tag "[https://commitfest.postgresql.org/?tag=44 PGConf.dev]".

Reviewers who want to participate look for patches with the tag and
sign up as reviewer.

<strike>Note: When you add the tag to an existing entry, you should remove all
existing reviewers. (Because we can't assume that those reviewers
will be at the conference or will participate in this.) The
commitfest managers will do this if necessary. If necessary, one can
add the previous reviewers back afterwards.</strike> (Edit: This requires CF admin privileges, so the commifest managers will do it.)

= Timeline =

* Signups are possible now (as of 10 April).

* Patches should be registered by 4 May at the latest (2 weeks before the conference). Later arrivals might not give reviewers enough time to prepare.

* Reviewers/committers sign up and prepare during those 2 weeks.

* Patch authors and reviewers meet during the week to discuss (perhaps more than once).

* We might present a summary or some statistics at the end of the conference week.

= Some rules =

* Obviously, both patch authors and reviewers must attend the conference.

* Maximum 2 patches per author (Consider the second one a backup if genuinely no one is available with expertise to review the first one.)

* More than one author or more than one reviewer is okay, but please coordinate this. The more people are involved, the harder it will be to find a time to meet.

* Everyone should sign up for themselves and as themselves. If you want to bring your team of co-authors or colleagues to the meeting, you should disclose this and request consent. Do not ambush your pairing partner with unexpected guests.

* Patches should be interesting enough to facilitate a conversation and learning experience. Patches that are trivial or mostly mechanical or that you do not understand yourself or that have already been thoroughly reviewed are not conducive.

* We are generally looking for two kinds of review pairings:
** Committer reviews patch by returning contributor. (It is assumed that the contributor generally knows their way around. The committer can help move the patch to completion.)
** Experienced developer reviews patch by new-ish contributor. (Here, the focus could be more on initial review and familiarization with process expectations, as well as getting to know.)
** (As a counterexample, it is normally useful for a new contributor to review a patch by an experienced contributor for oversights, usability, portability, etc., but this is probably not appropriate for this in-person event.)

The commitfest managers may reach out to involved parties or make adjustments of registered patches to facilitate this.

* Patches may be in need of either technical review or process guidance (or both). Use tags in the commitfest app judiciously to indicate your needs.

* The conference [https://2026.pgconf.dev/about/code-of-conduct code of conduct] applies.

* The event begins when the conference begins and ends when the conference ends. You are encouraged to keep working beyond that, of course, but that will be outside the scope of this event.

= The process before and during the conference =

* Patches should be in "Needs review" state before reviewer signup begins.

* Patches should pass Cirrus CI. (Unless this is the subject of the review, in which case use additional tags indicating this.)

* <strike>When adding the "PGConf.dev" tag, clear out existing reviewer entries.</strike>

* Reviewers study the patch ahead of the conference.

* Patch authors and reviewers meet during the conference to discuss feedback and decide on next steps.

* To find each other in person, if you don't know each other, in general, patch authors should reach out to reviewers to establish communication channels and arrange meetings (rather than the other way around). This will likely work better because you will have a better chance getting help at the conference locating a well-known committer than locating a first-time conference attendee or similar.

* Many experienced contributors will be very busy on Tuesday (community discussions) and Friday (unconference), so the best days to meet are probably Wednesday and Thursday. But you should already try to make contact before that.

* Room "Xerox" (Room 1500) is available for these meetings. (There will be a few other meetings in this room, but it is mostly free.) You can meet anywhere else, of course, but this should be the most comfortable. Note that this is not reserved for individual pairings, please share appropriately.

* Don't forget to post a review on pgsql-hackers, or at least a note that you met and discussed the patch, to keep everyone else in the loop.

* Set patch status to "Waiting on author" or "Ready for committer" as appropriate. This is at least to have some fun stats for this event at the end of the week.

= Communicating =

* The organizer of this event (that is, the commitfest manager) is Peter Eisentraut <peter@eisentraut.org>. Contact him with questions.

* The information desk at the conference might be a good place to get help finding rooms and people.

* The conference Discord server is the place to connect with attendees, find your review partners, etc.

* The [https://2026.pgconf.dev/about conference organizers] can be contacted for higher-level questions.

* There is a conference [https://2026.pgconf.dev/about/code-of-conduct code of conduct committee].

* The PostgreSQL Hacking Discord server and the pgsql-hackers mailing list should be used for discussing issues related to the technical contents of a patch.

* This wiki page may be updated from time to time with emerging generally useful information.

[[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2026 SQL Standard Workshop

2026-04-20T09:59:40Z

Petere:

https://2026.pgconf.dev/session/553

This is a workshop, so it's meant to be interactive.

* There is no separate registration for this workshop, but you can help the organizer by letting them know if you plan to attend.
** either: Peter Eisentraut <peter@eisentraut.org>
** or: PostgreSQL Hacking Discord server channel #sql-standard-dev or DM

* This workshop runs over lunch, but lunch will be served in the room.

* The room is not used after the workshop (except for commitfest meetings), so we can extend or keep working in smaller groups if necessary.

* Here are some things we could do, depending on the participants:
** Bring your own copy of the standard if you have it, else we can help you on site.
** Introduction on how the standard is written, how to read it, what different terms and sections mean.
** Try to solve interpretation questions, "what does the standard say about X" questions, solve problems you might have had. (Bring your questions.)
** Discuss what we might want to add to the standard and how.
** Look through the current CD consultation comments and try to address them. (You will learn what this means.)
** Write your own first change proposal paper (either during the workshop or separately afterwards), so submit to the June committee meeting.

[[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2026 SQL Standard Workshop

2026-04-13T05:31:09Z

Petere:

https://2026.pgconf.dev/session/553

TODO

[[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2026 SQL Standard Workshop

2026-04-13T05:30:17Z

Petere: created page

https://2026.pgconf.dev/session/553

TODO

PGConf.dev 2026

2026-04-13T05:29:12Z

Petere: /* Wiki Pages related to the conference */

PostgreSQL Development Conference 2026 ([https://2026.pgconf.dev PGConf.dev 2026]) will take place in ''Vancouver, Canada''.

== Resources ==

* [https://2026.pgconf.dev Website]
* [https://www.pgevents.ca/events/pgconfdev2026/schedule/ Schedule + Slides]
* Recordings (later)

== Wiki Pages related to the conference ==

* [[PGConf.dev 2026 Developer Unconference]]
* [[PGConf.dev 2026 In-Person Commitfest]]
* [[PGConf.dev 2026 SQL Standard Workshop]]
* [[PGConf.dev 2026 Translators and Translation Tooling]]

== Blog Postings and Videos ==

* (later)

[[Category:Unconference]] [[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2026 In-Person Commitfest

2026-04-10T17:28:18Z

Petere: /* The process before and during the conference */

https://www.pgevents.ca/events/pgconfdev2026/schedule/session/578-special-pgconfdev-in-person-commitfest/

The special PGConf.dev in-person commitfest runs during the week of
[[PGConf.dev 2026]]. Patches are registered and reviewers are assigned ahead
of the conference. Patch authors and reviewers meet during the
conference week as individually agreed to discuss the patches and if
appropriate move them closer to "Ready for Committer" status.

This gives all interested patch authors an opportunity to meet with
and learn from experienced developers in person, and it can help
facilitate moving some development projects forward in anticipation of
the next PostgreSQL development cycle.

------

The information and rules below are meant to give participants and
organizers some guidelines for how to operate this event, but they are
not meant to be in the way of having an enjoyable and productive
event. If there is something beyond what is discussed here, check
with the organizers and/or give it a try. The main goal is to learn
together.

= How to participate =

Every conference attendee can participate. You participate by
submitting a patch (see below) or signing up to review a patch. No
further signup beyond that exists.

= Submitting a patch / Signing up to review =

This event will be run on top of the PostgreSQL [[Commitfest]] system.
Patches should be submitted to either commitfest [https://commitfest.postgresql.org/59/ PG20-1] or [https://commitfest.postgresql.org/60/ PG20-Drafts]
and tagged with the tag "[https://commitfest.postgresql.org/?tag=44 PGConf.dev]".

Reviewers who want to participate look for patches with the tag and
sign up as reviewer.

Note: When you add the tag to an existing entry, you should remove all
existing reviewers. (Because we can't assume that those reviewers
will be at the conference or will participate in this.) The
commitfest managers will do this if necessary. If necessary, one can
add the previous reviewers back afterwards.

= Timeline =

* Signups are possible now (as of 10 April).

* Patches should be registered by 4 May at the latest (2 weeks before the conference). Later arrivals might not give reviewers enough time to prepare.

* Reviewers/committers sign up and prepare during those 2 weeks.

* Patch authors and reviewers meet during the week to discuss (perhaps more than once).

* We might present a summary or some statistics at the end of the conference week.

= Some rules =

* Obviously, both patch authors and reviewers must attend the conference.

* Maximum 2 patches per author (Consider the second one a backup if genuinely no one is available with expertise to review the first one.)

* More than one author or more than one reviewer is okay, but please coordinate this. The more people are involved, the harder it will be to find a time to meet.

* Everyone should sign up for themselves and as themselves. If you want to bring your team of co-authors or colleagues to the meeting, you should disclose this and request consent. Do not ambush your pairing partner with unexpected guests.

* Patches should be interesting enough to facilitate a conversation and learning experience. Patches that are trivial or mostly mechanical or that you do not understand yourself or that have already been thoroughly reviewed are not conducive.

* We are generally looking for two kinds of review pairings:
** Committer reviews patch by returning contributor. (It is assumed that the contributor generally knows their way around. The committer can help move the patch to completion.)
** Experienced developer reviews patch by new-ish contributor. (Here, the focus could be more on initial review and familiarization with process expectations, as well as getting to know.)
** (As a counterexample, it is normally useful for a new contributor to review a patch by an experienced contributor for oversights, usability, portability, etc., but this is probably not appropriate for this in-person event.)

The commitfest managers may reach out to involved parties or make adjustments of registered patches to facilitate this.

* Patches may be in need of either technical review or process guidance (or both). Use tags in the commitfest app judiciously to indicate your needs.

* The conference [https://2026.pgconf.dev/about/code-of-conduct code of conduct] applies.

* The event begins when the conference begins and ends when the conference ends. You are encouraged to keep working beyond that, of course, but that will be outside the scope of this event.

= The process before and during the conference =

* Patches should be in "Needs review" state before reviewer signup begins.

* Patches should pass Cirrus CI. (Unless this is the subject of the review, in which case use additional tags indicating this.)

* When adding the "PGConf.dev" tag, clear out existing reviewer entries.

* Reviewers study the patch ahead of the conference.

* Patch authors and reviewers meet during the conference to discuss feedback and decide on next steps.

* To find each other in person, if you don't know each other, in general, patch authors should reach out to reviewers to establish communication channels and arrange meetings (rather than the other way around). This will likely work better because you will have a better chance getting help at the conference locating a well-known committer than locating a first-time conference attendee or similar.

* Many experienced contributors will be very busy on Tuesday (community discussions) and Friday (unconference), so the best days to meet are probably Wednesday and Thursday. But you should already try to make contact before that.

* Room "Xerox" (Room 1500) is available for these meetings. (There will be a few other meetings in this room, but it is mostly free.) You can meet anywhere else, of course, but this should be the most comfortable. Note that this is not reserved for individual pairings, please share appropriately.

* Don't forget to post a review on pgsql-hackers, or at least a note that you met and discussed the patch, to keep everyone else in the loop.

* Set patch status to "Waiting on author" or "Ready for committer" as appropriate. This is at least to have some fun stats for this event at the end of the week.

= Communicating =

* The organizer of this event (that is, the commitfest manager) is Peter Eisentraut <peter@eisentraut.org>. Contact him with questions.

* The information desk at the conference might be a good place to get help finding rooms and people.

* The conference Discord server is the place to connect with attendees, find your review partners, etc.

* The [https://2026.pgconf.dev/about conference organizers] can be contacted for higher-level questions.

* There is a conference [https://2026.pgconf.dev/about/code-of-conduct code of conduct committee].

* The PostgreSQL Hacking Discord server and the pgsql-hackers mailing list should be used for discussing issues related to the technical contents of a patch.

* This wiki page may be updated from time to time with emerging generally useful information.

[[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2026 In-Person Commitfest

2026-04-10T17:28:03Z

Petere: /* Submitting a patch / Signing up to review */

https://www.pgevents.ca/events/pgconfdev2026/schedule/session/578-special-pgconfdev-in-person-commitfest/

The special PGConf.dev in-person commitfest runs during the week of
[[PGConf.dev 2026]]. Patches are registered and reviewers are assigned ahead
of the conference. Patch authors and reviewers meet during the
conference week as individually agreed to discuss the patches and if
appropriate move them closer to "Ready for Committer" status.

This gives all interested patch authors an opportunity to meet with
and learn from experienced developers in person, and it can help
facilitate moving some development projects forward in anticipation of
the next PostgreSQL development cycle.

------

The information and rules below are meant to give participants and
organizers some guidelines for how to operate this event, but they are
not meant to be in the way of having an enjoyable and productive
event. If there is something beyond what is discussed here, check
with the organizers and/or give it a try. The main goal is to learn
together.

= How to participate =

Every conference attendee can participate. You participate by
submitting a patch (see below) or signing up to review a patch. No
further signup beyond that exists.

= Submitting a patch / Signing up to review =

This event will be run on top of the PostgreSQL [[Commitfest]] system.
Patches should be submitted to either commitfest [https://commitfest.postgresql.org/59/ PG20-1] or [https://commitfest.postgresql.org/60/ PG20-Drafts]
and tagged with the tag "[https://commitfest.postgresql.org/?tag=44 PGConf.dev]".

Reviewers who want to participate look for patches with the tag and
sign up as reviewer.

Note: When you add the tag to an existing entry, you should remove all
existing reviewers. (Because we can't assume that those reviewers
will be at the conference or will participate in this.) The
commitfest managers will do this if necessary. If necessary, one can
add the previous reviewers back afterwards.

= Timeline =

* Signups are possible now (as of 10 April).

* Patches should be registered by 4 May at the latest (2 weeks before the conference). Later arrivals might not give reviewers enough time to prepare.

* Reviewers/committers sign up and prepare during those 2 weeks.

* Patch authors and reviewers meet during the week to discuss (perhaps more than once).

* We might present a summary or some statistics at the end of the conference week.

= Some rules =

* Obviously, both patch authors and reviewers must attend the conference.

* Maximum 2 patches per author (Consider the second one a backup if genuinely no one is available with expertise to review the first one.)

* More than one author or more than one reviewer is okay, but please coordinate this. The more people are involved, the harder it will be to find a time to meet.

* Everyone should sign up for themselves and as themselves. If you want to bring your team of co-authors or colleagues to the meeting, you should disclose this and request consent. Do not ambush your pairing partner with unexpected guests.

* Patches should be interesting enough to facilitate a conversation and learning experience. Patches that are trivial or mostly mechanical or that you do not understand yourself or that have already been thoroughly reviewed are not conducive.

* We are generally looking for two kinds of review pairings:
** Committer reviews patch by returning contributor. (It is assumed that the contributor generally knows their way around. The committer can help move the patch to completion.)
** Experienced developer reviews patch by new-ish contributor. (Here, the focus could be more on initial review and familiarization with process expectations, as well as getting to know.)
** (As a counterexample, it is normally useful for a new contributor to review a patch by an experienced contributor for oversights, usability, portability, etc., but this is probably not appropriate for this in-person event.)

The commitfest managers may reach out to involved parties or make adjustments of registered patches to facilitate this.

* Patches may be in need of either technical review or process guidance (or both). Use tags in the commitfest app judiciously to indicate your needs.

* The conference [https://2026.pgconf.dev/about/code-of-conduct code of conduct] applies.

* The event begins when the conference begins and ends when the conference ends. You are encouraged to keep working beyond that, of course, but that will be outside the scope of this event.

= The process before and during the conference =

* Patches should be in "Needs review" state before reviewer signup begins.

* Patches should pass Cirrus CI. (Unless this is the subject of the review, in which case use additional tags indicating this.)

* When adding the "PGConf.dev" tag, clear out existing reviewer entries.

* Reviewers study the patch ahead of the conference.

* Patch authors and reviewers meet during the conference to discuss feedback and decide on next steps.

* To find each other in person, if you don't know each other, in general, patch authors should reach out to reviewers to establish communication channels and arrange meetings (rather than the other way around). This will likely work better because you will have a better chance getting help at the conference locating a well-known committer than locating a first-time conference attendee or similar.

* Many experienced contributors will be very busy on Tuesday (community discussions) and Friday (unconference), so the best days to meet are probably Wednesday and Thursday. But you should already try to make contact before that.

* Room "Xerox" (Room 1500) is available for these meetings. (There will be a few other meetings in this room, but it is mostly free.) You can meet anywhere else, of course, but this should be the most comfortable. Note that this is not reserved for individual pairings, please share appropriately.

- Don't forget to post a review on pgsql-hackers, or at least a note that you met and discussed the patch, to keep everyone else in the loop.

- Set patch status to "Waiting on author" or "Ready for committer" as appropriate. This is at least to have some fun stats for this event at the end of the week.

= Communicating =

* The organizer of this event (that is, the commitfest manager) is Peter Eisentraut <peter@eisentraut.org>. Contact him with questions.

* The information desk at the conference might be a good place to get help finding rooms and people.

* The conference Discord server is the place to connect with attendees, find your review partners, etc.

* The [https://2026.pgconf.dev/about conference organizers] can be contacted for higher-level questions.

* There is a conference [https://2026.pgconf.dev/about/code-of-conduct code of conduct committee].

* The PostgreSQL Hacking Discord server and the pgsql-hackers mailing list should be used for discussing issues related to the technical contents of a patch.

* This wiki page may be updated from time to time with emerging generally useful information.

[[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2026 In-Person Commitfest

2026-04-10T12:04:53Z

Petere: created page

https://www.pgevents.ca/events/pgconfdev2026/schedule/session/578-special-pgconfdev-in-person-commitfest/

The special PGConf.dev in-person commitfest runs during the week of
[[PGConf.dev 2026]]. Patches are registered and reviewers are assigned ahead
of the conference. Patch authors and reviewers meet during the
conference week as individually agreed to discuss the patches and if
appropriate move them closer to "Ready for Committer" status.

This gives all interested patch authors an opportunity to meet with
and learn from experienced developers in person, and it can help
facilitate moving some development projects forward in anticipation of
the next PostgreSQL development cycle.

------

The information and rules below are meant to give participants and
organizers some guidelines for how to operate this event, but they are
not meant to be in the way of having an enjoyable and productive
event. If there is something beyond what is discussed here, check
with the organizers and/or give it a try. The main goal is to learn
together.

= How to participate =

Every conference attendee can participate. You participate by
submitting a patch (see below) or signing up to review a patch. No
further signup beyond that exists.

= Submitting a patch / Signing up to review =

This event will be run on top of the PostgreSQL [[Commitfest]] system.
Patches should be submitted to either commitfest [https://commitfest.postgresql.org/59/ PG20-1] or [https://commitfest.postgresql.org/60/ PG20-Drafts]
and tagged with the tag "[https://commitfest.postgresql.org/?tag=34 PGConf.dev]".

Reviewers who want to participate look for patches with the tag and
sign up as reviewer.

Note: When you add the tag to an existing entry, you should remove all
existing reviewers. (Because we can't assume that those reviewers
will be at the conference or will participate in this.) The
commitfest managers will do this if necessary. If necessary, one can
add the previous reviewers back afterwards.

= Timeline =

* Signups are possible now (as of 10 April).

* Patches should be registered by 4 May at the latest (2 weeks before the conference). Later arrivals might not give reviewers enough time to prepare.

* Reviewers/committers sign up and prepare during those 2 weeks.

* Patch authors and reviewers meet during the week to discuss (perhaps more than once).

* We might present a summary or some statistics at the end of the conference week.

= Some rules =

* Obviously, both patch authors and reviewers must attend the conference.

* Maximum 2 patches per author (Consider the second one a backup if genuinely no one is available with expertise to review the first one.)

* More than one author or more than one reviewer is okay, but please coordinate this. The more people are involved, the harder it will be to find a time to meet.

* Everyone should sign up for themselves and as themselves. If you want to bring your team of co-authors or colleagues to the meeting, you should disclose this and request consent. Do not ambush your pairing partner with unexpected guests.

* Patches should be interesting enough to facilitate a conversation and learning experience. Patches that are trivial or mostly mechanical or that you do not understand yourself or that have already been thoroughly reviewed are not conducive.

* We are generally looking for two kinds of review pairings:
** Committer reviews patch by returning contributor. (It is assumed that the contributor generally knows their way around. The committer can help move the patch to completion.)
** Experienced developer reviews patch by new-ish contributor. (Here, the focus could be more on initial review and familiarization with process expectations, as well as getting to know.)
** (As a counterexample, it is normally useful for a new contributor to review a patch by an experienced contributor for oversights, usability, portability, etc., but this is probably not appropriate for this in-person event.)

The commitfest managers may reach out to involved parties or make adjustments of registered patches to facilitate this.

* Patches may be in need of either technical review or process guidance (or both). Use tags in the commitfest app judiciously to indicate your needs.

* The conference [https://2026.pgconf.dev/about/code-of-conduct code of conduct] applies.

* The event begins when the conference begins and ends when the conference ends. You are encouraged to keep working beyond that, of course, but that will be outside the scope of this event.

= The process before and during the conference =

* Patches should be in "Needs review" state before reviewer signup begins.

* Patches should pass Cirrus CI. (Unless this is the subject of the review, in which case use additional tags indicating this.)

* When adding the "PGConf.dev" tag, clear out existing reviewer entries.

* Reviewers study the patch ahead of the conference.

* Patch authors and reviewers meet during the conference to discuss feedback and decide on next steps.

* To find each other in person, if you don't know each other, in general, patch authors should reach out to reviewers to establish communication channels and arrange meetings (rather than the other way around). This will likely work better because you will have a better chance getting help at the conference locating a well-known committer than locating a first-time conference attendee or similar.

* Many experienced contributors will be very busy on Tuesday (community discussions) and Friday (unconference), so the best days to meet are probably Wednesday and Thursday. But you should already try to make contact before that.

* Room "Xerox" (Room 1500) is available for these meetings. (There will be a few other meetings in this room, but it is mostly free.) You can meet anywhere else, of course, but this should be the most comfortable. Note that this is not reserved for individual pairings, please share appropriately.

- Don't forget to post a review on pgsql-hackers, or at least a note that you met and discussed the patch, to keep everyone else in the loop.

- Set patch status to "Waiting on author" or "Ready for committer" as appropriate. This is at least to have some fun stats for this event at the end of the week.

= Communicating =

* The organizer of this event (that is, the commitfest manager) is Peter Eisentraut <peter@eisentraut.org>. Contact him with questions.

* The information desk at the conference might be a good place to get help finding rooms and people.

* The conference Discord server is the place to connect with attendees, find your review partners, etc.

* The [https://2026.pgconf.dev/about conference organizers] can be contacted for higher-level questions.

* There is a conference [https://2026.pgconf.dev/about/code-of-conduct code of conduct committee].

* The PostgreSQL Hacking Discord server and the pgsql-hackers mailing list should be used for discussing issues related to the technical contents of a patch.

* This wiki page may be updated from time to time with emerging generally useful information.

[[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2026 Translators and Translation Tooling

2026-04-10T10:45:19Z

Petere: created page

PGConf.dev 2026

2026-04-10T10:26:03Z

Petere: /* Wiki Pages related to the conference */

PostgreSQL Development Conference 2026 ([https://2026.pgconf.dev PGConf.dev 2026]) will take place in ''Vancouver, Canada''.

== Resources ==

* [https://2026.pgconf.dev Website]
* [https://www.pgevents.ca/events/pgconfdev2026/schedule/ Schedule + Slides]
* Recordings (later)

== Wiki Pages related to the conference ==

* [[PGConf.dev 2026 Developer Unconference]]
* [[PGConf.dev 2026 In-Person Commitfest]]
* [[PGConf.dev 2026 Translators and Translation Tooling]]

== Blog Postings and Videos ==

* (later)

[[Category:Unconference]] [[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2026

2026-04-10T10:07:42Z

Petere: /* Wiki Pages related to the conference */ add link to commitfest

PostgreSQL Development Conference 2026 ([https://2026.pgconf.dev PGConf.dev 2026]) will take place in ''Vancouver, Canada''.

== Resources ==

* [https://2026.pgconf.dev Website]
* [https://www.pgevents.ca/events/pgconfdev2026/schedule/ Schedule + Slides]
* Recordings (later)

== Wiki Pages related to the conference ==

* [[PGConf.dev 2026 Developer Unconference]]
* [[PGConf.dev 2026 In-Person Commitfest]]

== Blog Postings and Videos ==

* (later)

[[Category:Unconference]] [[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2026

2026-04-10T09:57:38Z

Petere: created page

PostgreSQL Development Conference 2026 ([https://2026.pgconf.dev PGConf.dev 2026]) will take place in ''Vancouver, Canada''.

== Resources ==

* [https://2026.pgconf.dev Website]
* [https://www.pgevents.ca/events/pgconfdev2026/schedule/ Schedule + Slides]
* Recordings (later)

== Wiki Pages related to the conference ==

* [[PGConf.dev 2026 Developer Unconference]]

== Blog Postings and Videos ==

* (later)

[[Category:Unconference]] [[Category:PGConf.dev]] [[Category:PGConf.dev 2026]]

PGConf.dev 2025

2026-04-10T09:07:15Z

Petere: /* Resources */ add YouTube playlist link

PostgreSQL Development Conference 2025 ([https://2025.pgconf.dev PGConf.dev 2025]) took place in ''Montreal, Canada''.

== Resources ==

* [https://2025.pgconf.dev Website]
* [https://www.pgevents.ca/events/pgconfdev2025/schedule/ Schedule + Slides]
* [https://youtube.com/playlist?list=PLTw6f6dqzO1tCLr_OHjZ37kY2r35u2tCq&si=yAR2shc_hrydUMzz Recordings]

== Wiki Pages related to the conference ==

* [[PGConf.dev 2025 Developer Unconference]]
* [[PGConf.dev 2025 Extension Summit]]
* [[PGConf.dev 2025 Community Summit]]
* [[PGConf.dev 2025 Developer Meeting]]

== Blog Postings and Videos ==

* https://hornetlabs.ca/2025/05/21/pgconf-dev-2025-wraps-up-with-great-success-in-montreal/

[[Category:Unconference]] [[Category:PGConf.dev]] [[Category:PGConf.dev 2025]]

Meson

2026-04-08T12:45:24Z

Petere: /* Windows */ use winflexbison3 package

== PostgreSQL devel documentation ==

See [https://www.postgresql.org/docs/devel/install-meson.html "Building and Installation with Meson" section] of PostgreSQL devel docs.

== Autoconf:meson command translations ==

NOTE: Make sure meson is version 0.57 or higher

=== Setup and build commands ===

{|class="wikitable" style="margin:auto"
!description
!old command
!new command
!comment
|-
|| set up build tree
|| <code>./configure [options]</code>
|| <code>meson setup [options] [builddir] sourcedir</code>
|| meson only supports building out of tree
|-
|| set up build tree for visual studio
|| <code>perl src/tools/msvc/mkvcbuild.pl</code>
|| <code>meson setup --backend vs [options] [builddir] sourcedir</code>
|| configures build tree for one build type (debug or release or ...)
|-
|| show configure options
|| <code>./configure --help</code>
|| <code>meson configure</code>
|| shows options built into meson and PostgreSQL specific options
|-
|| set configure options
|| <code>./configure --prefix=DIR, --$somedir=DIR, --with-$option, --enable-$feature</code>
|| <code>meson setup|configure -D$option=$value</code>
|| options can be set when setting up build tree (setup) and in existing build tree (configure)
|-
|| enable cassert
|| <code>--enable-cassert</code>
|| <code>-Dcassert=true</code>
||
|-
|| enable debug symbols
|| <code>./configure --enable-debug</code>
|| <code>meson configure|setup -Ddebug=true</code>
||
|-
|| specify compiler
|| <code>CC=compiler ./configure</code>
|| <code>CC=compiler meson setup</code>
|| <code>CC</code> is only checked during meson setup, not with meson configure
|-
|| set CFLAGS
|| <code>CFLAGS=options ./configure</code>
|| <code>meson configure|setup -Dc_args=options</code>
|| <code>CFLAGS</code> is also checked, but only for meson setup
|-
|| build
|| <code>make -s</code>
|| <code>ninja</code>
|| ninja uses parallelism by default, launch from the root of the build tree.
|-
|| build, showing compiler commands
|| <code>make</code>
|| <code>ninja -v</code>
|| ninja uses parallelism by default, launch from the root of the build tree.
|-
|| build the documentation
|| <code>make docs</code>
|| <code>ninja docs</code>
|| ninja's default target builds everything except the docs.
|-
|| install all the binaries and libraries
|| <code>make install</code>
|| <code>ninja install</code>
|| use <code>meson install --quiet</code> for a less verbose experience
|-
|| install files that changed only
||
|| <code>meson install --only-changed</code>
|| Routinely shaves a few hundred milliseconds off install time
|-
|| clean build
|| <code>make clean</code>
|| <code>ninja clean</code>
|| ninja uses parallelism by default, launch from the root of the build tree.
|-
|| build documentation
|| <code>cd doc/ && make html && make man</code>
|| <code>ninja docs</code>
|| Builds html documentation and man pages
|}

==== Build directory ====

ninja tries to run from the root of the build directory. If you are not in the build directory, you can use the <code>-C</code> flag to have ninja "change directory" and run from there, e.g.:

<pre>
ninja -C $builddir
</pre>

=== Test related commands ===

{|class="wikitable" style="margin:auto"
!description
!old command
!new command
!comment
|-
|| list tests
||
|| <code>meson test --list</code>
|| Only shows tests from "tmp_install" [https://mesonbuild.com/Reference-manual_functions.html#add_test_setup test setup], since it is the default (<code>--setup tmp_install</code> is implied here)
|-
|| install test files not installed by default
||
|| <code>ninja install-test-files</code>
|| not needed for the main regression tests, but various others will fail without this
|-
|| list running/installcheck test variants
||
|| <code>meson test --setup running --list</code>
|| "running" [https://mesonbuild.com/Reference-manual_functions.html#add_test_setup test setup] is used to run tests against an existing server
|-
|| run all tests
|| <code>make check-world</code>
|| <code>meson test -q --print-errorlogs</code>
|| runs all test, using parallelism by default
|-
|| run all tests against existing server
|| <code>make installcheck-world</code>
|| <code>meson test -q --print-errorlogs --setup running</code>
|| Currently [https://postgr.es/m/CAH2-Wz=X7=5jU-+XXJaqQRZja_fseEtrd_dGJa0Wpb74OpsgEA@mail.gmail.com makes brittle assumptions] about test libraries being installed
|-
|| run main regression tests
|| <code>make check</code>
|| <code>meson test -q --print-errorlogs --suite setup --suite regress</code>
|| <code>--suite setup</code> required to get a <code>tmp_install</code> directory; see below
|-
|| run a few specific regression tests
|| <code>make check-tests TESTS="test_setup boolean char"</code>
|| <code>meson test -q --print-errorlogs --suite setup && TESTS="test_setup boolean char" meson test -v --print-errorlogs --suite regress</code>
|| <code>--suite setup</code> required to get a <code>tmp_install</code> directory; see below. Also, sometimes tests have dependencies on objects created by other tests (e.g., test_setup, create_index), which can cause unexpected failures. For full details see <code>src/test/regress/parallel_schedule</code>.
|-
|| run specific contrib test suite
|| <code>make -C contrib/amcheck check</code>
|| <code>meson test -q --print-errorlogs --suite setup --suite amcheck</code>
|| <code>--suite setup</code> required to get a <code>tmp_install</code> directory; see below.
|-
|| run a few specific Perl TAP tests
||
|| <code>meson test -q --print-errorlogs --suite setup && meson test -q --print-errorlogs recovery/013_crash_restart recovery/027_stream_regress</code>
|| <code>--suite setup</code> required to get a <code>tmp_install</code> directory; see below
|-
|| run Perl TAP tests matching a wildcard pattern
||
|| <code>meson test -q --print-errorlogs --suite setup && meson test -q --print-errorlogs '*archive*'</code>
|| <code>--suite setup</code> required to get a <code>tmp_install</code> directory; see below
|-
|| run main regression tests against existing server
|| <code>make installcheck</code>
|| <code>meson test -q --print-errorlogs --setup running --suite regress-running</code>
||
|-
|| run a few specific regression tests against existing server
|| <code>make installcheck-tests TESTS="test_setup boolean char"</code>
|| <code>TESTS="test_setup boolean char" meson test -v --print-errorlogs --suite regress-running</code>
|| Sometimes tests have dependencies on objects created by other tests (e.g., test_setup, create_index), which can cause unexpected failures. For full details see <code>src/test/regress/parallel_schedule</code>.
|-
|| run specific contrib test suite against existing server
|| <code>make -C contrib/amcheck installcheck</code>
|| <code>meson test -q --print-errorlogs --setup running --suite amcheck-running</code>
|| "running" amcheck suite variant doesn't include TAP tests
|-
|| run a few specific isolation tests
||
|| <code>meson test -q --print-errorlogs --suite setup && TESTS="freeze-the-dead vacuum-no-cleanup-lock" meson test -v --print-errorlogs --suite isolation</code>
|| <code>--suite setup</code> required to get a <code>tmp_install</code> directory; see below
|}

==== Test structure ====

When running a specific test suite against a temporary throw away installation, <code>--suite setup</code> should generally be specified. Otherwise the tests could end up running against a stale <code>tmp_install</code> directory, causing general confusion. This [https://postgr.es/m/20230209205605.zo5gfhli22g2kdm2@awork3.anarazel.de workaround] is not required when running tests against an existing server (via the <code>running</code> test setup and variant test suites), since of course the installation directory being tested is whatever directory the external server installation uses.

Note that the top-level/default project name is <code>postgresql</code>, which is the only one we use in practice. The project name [https://mesonbuild.com/Unit-tests.html#run-subsets-of-tests can be omitted] when using a reasonably recent meson version (meson 0.46 or later), which we assume here.

You can list all of the tests from a given suite as follows:

<pre>
/path/to/postgresql/build_meson $ meson test --list --suite amcheck
ninja: no work to do.
postgresql:amcheck / amcheck/regress
postgresql:amcheck / amcheck/001_verify_heapam
postgresql:amcheck / amcheck/002_cic
postgresql:amcheck / amcheck/003_cic_2pc
</pre>

Note that there are distinct <code>running</code>/installcheck suites for most of the standard setup suites, though not all of the tests actually carry over to the <code>running</code> variant suites, as shown here:
<pre>
/path/to/postgresql/build_meson $ meson test --list --suite amcheck-running
ninja: no work to do.
postgresql:amcheck-running / amcheck-running/regress
</pre>

== Installing Meson ==

=== FreeBSD ===

<pre>
pkg install meson ninja
</pre>

Arguments to meson setup/configure to find ports libraries:
<pre>
meson setup -Dextra_lib_dirs=/opt/local/lib -Dextra_include_dirs=/opt/local/include $builddir $sourcedir
</pre>

=== Linux ===

Debian / Ubuntu:
<pre>
apt-get update && apt-get install -y meson ninja-build
</pre>

Fedora:
<pre>
dnf -y install meson ninja-build
</pre>

RHEL 8:
<pre>
dnf -y install dnf-plugins-core
dnf config-manager --set-enabled powertools
dnf -y install meson ninja-build
</pre>

RHEL 9 (tested on Rocky Linux 9):
<pre>
dnf -y install dnf-plugins-core
dnf config-manager --set-enabled crb
dnf -y install meson
</pre>

=== macOS ===

With MacPorts:

<pre>
sudo port install meson
</pre>

Arguments to meson setup/configure to find MacPorts libraries:
<pre>
meson setup -Dpkg_config_path=/opt/local/lib/pkgconfig -Dextra_lib_dirs=/opt/local/lib/ -Dextra_include_dirs=/opt/local/include $builddir $sourcedir
</pre>

With Homebrew:
<pre>
brew install meson
</pre>

Arguments to meson setup/configure to find Homebrew libraries:

On arm64:
<pre>
meson setup -Dpkg_config_path=/opt/homebrew/lib/pkgconfig -Dextra_include_dirs=/opt/homebrew/include -Dextra_lib_dirs=/opt/homebrew/lib $builddir $sourcedir
</pre>

On x86-64:
<pre>
meson setup -Dpkg_config_path=/usr/local/lib/pkgconfig -Dextra_include_dirs=/usr/local/include -Dextra_lib_dirs=/usr/local/lib $builddir $sourcedir
</pre>

=== Windows ===

Assuming python is installed, the easiest way to get meson and ninja is:
<pre>
pip install meson ninja
</pre>

As documented on the [https://mesonbuild.com/Getting-meson.html meson website], a MSI installer is also available.

Using the most recent version of ActivePerl may be a bit challenging, as there is no direct access to a "perl" command except if enabling a project registered in the ActivePerl website, with a command like that:
<pre>
state activate --default
</pre>

An easy way to set up things is to install Chocolatey, and rely on StrawberryPerl. Here are the main packages to worry about:
<pre>
choco install winflexbison3
choco install sed
choco install gzip
choco install strawberryperl
choco install diffutils
</pre>

The compiler detected will depend on the Command Prompt type used. For MSVC, use the command prompt installed for VS. A native Command prompt or Powershell may finish by linking to Chocolatey's gcc, which may be OK, still be careful with what's reported by meson setup.

== Why and What ==

Autoconf is showing its age, fewer and fewer contributors know how to wrangle
it. Recursive make has a lot of hard to resolve dependency issues and slow
incremental rebuilds. Our home-grown MSVC buildsystem is hard to maintain for
developers not using windows and runs tests serially. While these and other
issues could individually be addressed with incremental improvements, together
they seem best addressed by moving to a more modern buildsystem.

After evaluating different buildsystem choices, we chose to use meson, to a
good degree based on the adoption by other open source projects.

We decided that it's more realistic to commit a relatively early version of
the new buildsystem and mature it in tree.

The plan is to remove the msvc specific buildsystem in src/tools/msvc soon
after reaching feature parity. However, we're not planning to remove the
autoconf/make buildsystem in the near future. Likely we're going to keep at
least the parts required for PGXS to keep working around until all supported
versions build with meson.

== Meson documentation ==

* [https://mesonbuild.com/Commands.html meson commandline commands]
* [https://mesonbuild.com/Syntax.html meson syntax]
* [https://mesonbuild.com/Reference-manual_functions.html meson functions]

== Development tree, other resources ==

* https://github.com/anarazel/postgres/tree/meson
* https://wiki.postgresql.org/wiki/PgCon_2022_Developer_Unconference#Meson_new_build_system_proposal

== Visualizing builds ==

When building with ninja, the generated .ninja_log can be uploaded to [https://ui.perfetto.dev/ ui.perfetto.dev], which is very helpful to visualize builds.

PostgreSQL 19 Open Items

2026-04-07T08:36:04Z

Petere: Fixed: pg_upgrade fails when extension_control_path is used

== Important Dates ==

Current schedule:

* Feature Freeze: April 8, 2026 12:00 UTC

== Decisions to Recheck Mid-Beta ==

* Do we want to keep the assertions added by commit {{PgCommitURL|7dcea51c2a4d}}
** Owner: Álvaro Herrera

* When exactly should we revert {{messageLink|DDPR5BPWH1RJ.1LWAK6QAURVAY%40jeltef.nl|protocol grease}}?
** Owner: Jacob Champion

== Open Issues ==

* {{messageLink|CAEze2WjP0NpAjNioXzLiNkpNQcxCMtaNajaQXfufYVcyFyqW1g%40mail.gmail.com|2=No method to block effective_wal_level=logical when wal_level=replica is needed}}

* Revert the beta-only grease patch ({{PgCommitURL|4966bd3ed}}) before RC1.
** Owner: Jacob Champion

* {{messageLink|ab0dcc9e-aba0-44e3-ac23-8d74c48888e6@postgrespro.ru|BM_IO_ERROR flag is lost in TerminateBufferIO due to order of operations in UnlockBufHdrExt}}
** Commit: {{PgCommitURL|c75ebc657ffc}} ?
** Owner: Andres Freund

* Should FOR PORTION OF use null values for unbounded ranges or a separate keyword?
** Commit: {{PgCommitURL|8e72d914c52}}
** Owner: Peter Eisentraut / Paul Jungwirth

'''NOTE''': Please place new open items at the end of the list.

'''NOTE''': If known, please list the Owner of the open item.

== Resolved Issues ==

=== resolved before 19beta1 ===

* {{messageLink|acMiT69EEGKHWGM5@paquier.xyz|2=Add tests for locks statistics}}
** Commit: {{PgCommitURL|7c64d56fd9765bb577937c07eabed971e605c67c}} removed the tests as unstable in the CI for Windows, at least.
** Fix: {{PgCommitURL|557a9f1e3e62}}
** Owner: Michael Paquier

* {{messageLink|C2133B47-79CD-40FF-B088-02D20D654806@gmail.com|Deferred foreign key checks mistakenly don't use batched path}}
** Commit: {{PgCommitURL|b7b27eb41a5}}
** Fix: {{PgCommitURL|5c54c3ed1b934}}
** Owner: Amit Langote

* {{messageLink|43b3691c673a8b9158f5a09f06eacc3c63e2c02d.camel@gmail.com|2=pg_upgrade fails when extension_control_path is used}}
** Commit: {{PgCommitURL|4f7f7b0375854e2f89876473405a8f21c95012af}} added this feature to 18; upgrading to 19 fails.
** Fix: {{PgCommitURL|1e67508730e}}
** Owner: Peter Eisentraut

== Non-bugs ==

== Won't Fix ==

== Older bugs affecting stable branches ==

=== Live issues ===

=== Fixed issues ===

== See also ==

* [[Release Management Team]]
* [[PostgreSQL 18 Open Items]]

[[Category:Open_Items]]

PostgreSQL 19 Open Items

2026-04-07T08:33:18Z

Petere: /* Open Issues */

== Important Dates ==

Current schedule:

* Feature Freeze: April 8, 2026 12:00 UTC

== Decisions to Recheck Mid-Beta ==

* Do we want to keep the assertions added by commit {{PgCommitURL|7dcea51c2a4d}}
** Owner: Álvaro Herrera

* When exactly should we revert {{messageLink|DDPR5BPWH1RJ.1LWAK6QAURVAY%40jeltef.nl|protocol grease}}?
** Owner: Jacob Champion

== Open Issues ==

* {{messageLink|CAEze2WjP0NpAjNioXzLiNkpNQcxCMtaNajaQXfufYVcyFyqW1g%40mail.gmail.com|2=No method to block effective_wal_level=logical when wal_level=replica is needed}}

* Revert the beta-only grease patch ({{PgCommitURL|4966bd3ed}}) before RC1.
** Owner: Jacob Champion

* {{messageLink|43b3691c673a8b9158f5a09f06eacc3c63e2c02d.camel@gmail.com|2=pg_upgrade fails when extension_control_path is used}}
** Commit: {{PgCommitURL|4f7f7b0375854e2f89876473405a8f21c95012af}} added this feature to 18; upgrading to 19 fails.
** Owner: Peter Eisentraut

* {{messageLink|ab0dcc9e-aba0-44e3-ac23-8d74c48888e6@postgrespro.ru|BM_IO_ERROR flag is lost in TerminateBufferIO due to order of operations in UnlockBufHdrExt}}
** Commit: {{PgCommitURL|c75ebc657ffc}} ?
** Owner: Andres Freund

* Should FOR PORTION OF use null values for unbounded ranges or a separate keyword?
** Commit: {{PgCommitURL|8e72d914c52}}
** Owner: Peter Eisentraut / Paul Jungwirth

'''NOTE''': Please place new open items at the end of the list.

'''NOTE''': If known, please list the Owner of the open item.

== Resolved Issues ==

=== resolved before 19beta1 ===

* {{messageLink|acMiT69EEGKHWGM5@paquier.xyz|2=Add tests for locks statistics}}
** Commit: {{PgCommitURL|7c64d56fd9765bb577937c07eabed971e605c67c}} removed the tests as unstable in the CI for Windows, at least.
** Fix: {{PgCommitURL|557a9f1e3e62}}
** Owner: Michael Paquier

* {{messageLink|C2133B47-79CD-40FF-B088-02D20D654806@gmail.com|Deferred foreign key checks mistakenly don't use batched path}}
** Commit: {{PgCommitURL|b7b27eb41a5}}
** Fix: {{PgCommitURL|5c54c3ed1b934}}
** Owner: Amit Langote

== Non-bugs ==

== Won't Fix ==

== Older bugs affecting stable branches ==

=== Live issues ===

=== Fixed issues ===

== See also ==

* [[Release Management Team]]
* [[PostgreSQL 18 Open Items]]

[[Category:Open_Items]]

FOSDEM/PGDay 2026 Developer Meeting

2026-01-30T17:13:46Z

Petere: /* Notes */

See https://2026.fosdempgday.org/devmeeting/ for venue and other general information.

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="font-style:italic;background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:10
|Welcome and introductions

|-
|09:10–09:30
|Review of the state of development processes and commitfests

|-
|09:30–09:50
|Planning for the upcoming beta period

Schedule, packaging, [[Release Management Team]], etc.

|-
|09:50–10:10
|What can we do to reduce the need for rebasing patches? (Daniel)

In the past, OID conflicts was a common reason for patches no longer applying,
and since we started recommending to use OIDs from a set, that has drastically
reduced. We also ask patches to not bump catalog version, which also helps, but
it's worth discussing if we can do more. Can we make a separate
guc_parameters.dat for patches in flight to remove GUC collisions from rebase
conflicts? Are there other causes of trivial conflicts we can remove?

|-
|10:10–10:30
|How to deal with patches that generate a lot of refactoring? (Bertrand)

If a refactoring idea is worth it and would need to update say 200 files with
say 1000 changes, how do we proceed? It probably has to be split to ease the review and to avoid rebases for patches
waiting in the commitfest.

|- style="font-style:italic;background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|Development project status mini-presentations (5 min presentation + 5 min Q&A and changeover)

# Tomas: index prefetching
# Bertrand: Coccinelle
# Amit: batching executor
# <s>Jeff</s> (Peter): locale and collation work ([[CollationStatus]])
# Peter: C11 and beyond adoption
# Bilal: Meson conversion
# Álvaro: repack
# Christoph: contributor badges

|- style="font-style:italic;background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–14:30
|Building the next generation of open source contributors, with Claire Giordano

(small presentation followed by discussion, inspired by this talk: https://fosdem.org/2026/schedule/event/JDZXFE-next-generation-contributors-lessons-from-postgres/)

|-
|14:30–15:00
|Dealing with near worthless/automated/synthetic patch submissions and reviews (Tomas)

|-
|15:00–15:25
|Commitfest website feedback and brainstorming

|-
|15:25–15:30
|Group photo

|- style="font-style:italic;background-color:lightgray;"
|15:30–16:00
|Tea

|-
|16:00–16:20
|Any other business

# Bruce: TDE
# Devrim: Distro support for the upcoming features

|-
|16:20–17:00
|Patch triage

(see below)

|}

(room available until 18:00)

== Participants ==

* Alexander Korotkov
* Álvaro Herrera
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Matthias van de Meent
* Nazir Bilal Yavuz
* Peter Eisentraut (organizer)
* Thomas Munro
* Tomas Vondra

== Patch triage ==

Attendees: Nominate patches to discuss during the patch triage section here. Additional patches can be added during the meeting, depending on the available time.

* https://commitfest.postgresql.org/patch/6050/ (Peter)
* [https://www.postgresql.org/message-id/CACG%3DezYeSygeb68tJVej9Qgji6k78V2reSqzh1_Y4P5GxCAGsw%40mail.gmail.com 64-bit xids] (Alexander)
* Logical Replication ([https://www.postgresql.org/message-id/CAMT0RQQx43yrCv5iB0A7H56VngTzw0gfJjVdwrtZ03ZMLWVk3g@mail.gmail.com "making tid and HOTness of UPDATE available to logical decoding plugins" etc.] (Matthias)
* …

== Group photo ==

[[File:Fosdem-pgday-dev-meeting-2026.jpeg|728px]]

== Notes ==

* Review of the state of development processes and commitfests
** discussion about having subsystem maintainers, to enable contact points for patch submissions; could use tags in CF app to organize this
** discussion about being able to follow patches without signing up as reviewer
** straw poll: 9–0 in favor of having only one commitfest per development cycle, provided some mechanism of aging out stale patches earlier

* reduce the need for rebasing patches
** sources of conflicts?
*** #includes
*** new GUCs added at end of lists (might be obsolete)
*** typos fixes
*** pg_proc.dat
** idea: pg_xxx.dat.new during patch development
** maybe reorder pg_proc.dat to discourage everyone trying to add new entries in the same place
** collect more data about conflict causes from cfbot?

* dealing with large refactoring patches
** split patches into series, large mechanical changes could use "nocfbot-" prefix
** some large changes could be parked for after feature freeze; register under Open Items
** discussion about backpatching impact

* Planning for the upcoming beta period
** RMT (Tomas):
*** regular meetings every two weeks were useful
*** question about what "mid-beta" means
** packaging:
*** getting extension authors to update their extensions for a new major release is a challenge every year
*** unclear when extensions are expected to be ready, some extension authors don't want to put in the work too early
*** suggestion: extension authors should start their work after the June/July beta, extensions ready for August beta (would need to be documented)

* synthetic patch submissions and reviews
** discussion on possible incentives (credit, work/school work, native language, experimentation), possible remedies

* Commitfest website feedback and brainstorming
** forwarded some of the discussion above to CF app developer
** "follow patch" could be the same as current "subscribe to patch" without email
** access control to CF app needs to be refined, currently only former CF managers can edit certain things such as tags
** the newly deployed automoving functionality will run for the first time on 1st Feb., exciting

* other
** Bruce: new PCI standard no longer allows disk encryption; temporary files compression work might make TDE work easier in the future
** Devrim: wants more advance notice of new or raised dependencies, authors/committers are encouraged to notify pgsql-packagers right away
** Christoph: straw poll: 9–0 in favor of disabling JIT by default

* patch triage
** 64-bit xids patch was discussed extensively, everyone is in favor of having it, work should continue

FOSDEM/PGDay 2026 Developer Meeting

2026-01-30T17:06:03Z

Petere: /* Schedule */

See https://2026.fosdempgday.org/devmeeting/ for venue and other general information.

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="font-style:italic;background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:10
|Welcome and introductions

|-
|09:10–09:30
|Review of the state of development processes and commitfests

|-
|09:30–09:50
|Planning for the upcoming beta period

Schedule, packaging, [[Release Management Team]], etc.

|-
|09:50–10:10
|What can we do to reduce the need for rebasing patches? (Daniel)

In the past, OID conflicts was a common reason for patches no longer applying,
and since we started recommending to use OIDs from a set, that has drastically
reduced. We also ask patches to not bump catalog version, which also helps, but
it's worth discussing if we can do more. Can we make a separate
guc_parameters.dat for patches in flight to remove GUC collisions from rebase
conflicts? Are there other causes of trivial conflicts we can remove?

|-
|10:10–10:30
|How to deal with patches that generate a lot of refactoring? (Bertrand)

If a refactoring idea is worth it and would need to update say 200 files with
say 1000 changes, how do we proceed? It probably has to be split to ease the review and to avoid rebases for patches
waiting in the commitfest.

|- style="font-style:italic;background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|Development project status mini-presentations (5 min presentation + 5 min Q&A and changeover)

# Tomas: index prefetching
# Bertrand: Coccinelle
# Amit: batching executor
# <s>Jeff</s> (Peter): locale and collation work ([[CollationStatus]])
# Peter: C11 and beyond adoption
# Bilal: Meson conversion
# Álvaro: repack
# Christoph: contributor badges

|- style="font-style:italic;background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–14:30
|Building the next generation of open source contributors, with Claire Giordano

(small presentation followed by discussion, inspired by this talk: https://fosdem.org/2026/schedule/event/JDZXFE-next-generation-contributors-lessons-from-postgres/)

|-
|14:30–15:00
|Dealing with near worthless/automated/synthetic patch submissions and reviews (Tomas)

|-
|15:00–15:25
|Commitfest website feedback and brainstorming

|-
|15:25–15:30
|Group photo

|- style="font-style:italic;background-color:lightgray;"
|15:30–16:00
|Tea

|-
|16:00–16:20
|Any other business

# Bruce: TDE
# Devrim: Distro support for the upcoming features

|-
|16:20–17:00
|Patch triage

(see below)

|}

(room available until 18:00)

== Participants ==

* Alexander Korotkov
* Álvaro Herrera
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Matthias van de Meent
* Nazir Bilal Yavuz
* Peter Eisentraut (organizer)
* Thomas Munro
* Tomas Vondra

== Patch triage ==

Attendees: Nominate patches to discuss during the patch triage section here. Additional patches can be added during the meeting, depending on the available time.

* https://commitfest.postgresql.org/patch/6050/ (Peter)
* [https://www.postgresql.org/message-id/CACG%3DezYeSygeb68tJVej9Qgji6k78V2reSqzh1_Y4P5GxCAGsw%40mail.gmail.com 64-bit xids] (Alexander)
* Logical Replication ([https://www.postgresql.org/message-id/CAMT0RQQx43yrCv5iB0A7H56VngTzw0gfJjVdwrtZ03ZMLWVk3g@mail.gmail.com "making tid and HOTness of UPDATE available to logical decoding plugins" etc.] (Matthias)
* …

== Group photo ==

[[File:Fosdem-pgday-dev-meeting-2026.jpeg|728px]]

== Notes ==

* Review of the state of development processes and commitfests
** discussion about having subsystem maintainers, to enable contact points for patch submissions; could use tags in CF app to organize this
** discussion about being able to follow patches without signing up as reviewer
** straw poll: 9–0 in favor of having only one commitfest per development cycle, provided some mechanism of aging out stale patches earlier

* reduce the need for rebasing patches
** sources of conflicts?
*** #includes
*** new GUCs added at end of lists (might be obsolete)
*** typos fixes
*** pg_proc.dat
** idea: pg_xxx.dat.new during patch development
** maybe reorder pg_proc.dat to discourage everyone trying to add new entries in the same place
** collect more data about conflict causes from cfbot?

* dealing with large refactoring patches
** split patches into series, large mechanical changes could use "nocfbot-" prefix
** some large changes could be parked for after feature freeze; register under Open Items
** discussion about backpatching impact

* Planning for the upcoming beta period
** RMT (Tomas):
*** regular meetings every two weeks were useful
*** question about what "mid-beta" means
** packaging:
*** getting extension authors to update their extensions for a new major release is a challenge every year
*** unclear when extensions are expected to be ready, some extension authors don't want to put in the work too early
*** suggestion: extension authors should start their work after the June/July beta, extensions ready for August beta (would need to be documented)

* Commitfest website feedback and brainstorming
** forwarded some of the discussion above to CF app developer
** "follow patch" could be the same as current "subscribe to patch" without email
** access control to CF app needs to be refined, currently only former CF managers can edit certain things such as tags
** the newly deployed automoving functionality will run for the first time on 1st Feb., exciting

FOSDEM/PGDay 2026 Developer Meeting

2026-01-30T17:04:43Z

Petere: /* Notes */

See https://2026.fosdempgday.org/devmeeting/ for venue and other general information.

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="font-style:italic;background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:10
|Welcome and introductions

|-
|09:10–09:30
|Review of the state of development processes and commitfests

|-
|09:30–09:50
|Planning for the upcoming beta period

Schedule, packaging, [[Release Management Team]], etc.

|-
|09:50–10:10
|What can we do to reduce the need for rebasing patches? (Daniel)

In the past, OID conflicts was a common reason for patches no longer applying,
and since we started recommending to use OIDs from a set, that has drastically
reduced. We also ask patches to not bump catalog version, which also helps, but
it's worth discussing if we can do more. Can we make a separate
guc_parameters.dat for patches in flight to remove GUC collisions from rebase
conflicts? Are there other causes of trivial conflicts we can remove?

|-
|10:10–10:30
|How to deal with patches that generate a lot of refactoring? (Bertrand)

If a refactoring idea is worth it and would need to update say 200 files with
say 1000 changes, how do we proceed? It probably has to be split to ease the review and to avoid rebases for patches
waiting in the commitfest.

|- style="font-style:italic;background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|Development project status mini-presentations (5 min presentation + 5 min Q&A and changeover)

# Tomas: index prefetching
# Bertrand: Coccinelle
# Amit: batching executor
# <s>Jeff</s> (Peter): locale and collation work
# Peter: C11 and beyond adoption
# Bilal: Meson conversion
# Álvaro: repack
# Christoph: contributor badges

|- style="font-style:italic;background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–14:30
|Building the next generation of open source contributors, with Claire Giordano

(small presentation followed by discussion, inspired by this talk: https://fosdem.org/2026/schedule/event/JDZXFE-next-generation-contributors-lessons-from-postgres/)

|-
|14:30–15:00
|Dealing with near worthless/automated/synthetic patch submissions and reviews (Tomas)

|-
|15:00–15:25
|Commitfest website feedback and brainstorming

|-
|15:25–15:30
|Group photo

|- style="font-style:italic;background-color:lightgray;"
|15:30–16:00
|Tea

|-
|16:00–16:20
|Any other business

# Bruce: TDE
# Devrim: Distro support for the upcoming features

|-
|16:20–17:00
|Patch triage

(see below)

|}

(room available until 18:00)

== Participants ==

* Alexander Korotkov
* Álvaro Herrera
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Matthias van de Meent
* Nazir Bilal Yavuz
* Peter Eisentraut (organizer)
* Thomas Munro
* Tomas Vondra

== Patch triage ==

Attendees: Nominate patches to discuss during the patch triage section here. Additional patches can be added during the meeting, depending on the available time.

* https://commitfest.postgresql.org/patch/6050/ (Peter)
* [https://www.postgresql.org/message-id/CACG%3DezYeSygeb68tJVej9Qgji6k78V2reSqzh1_Y4P5GxCAGsw%40mail.gmail.com 64-bit xids] (Alexander)
* Logical Replication ([https://www.postgresql.org/message-id/CAMT0RQQx43yrCv5iB0A7H56VngTzw0gfJjVdwrtZ03ZMLWVk3g@mail.gmail.com "making tid and HOTness of UPDATE available to logical decoding plugins" etc.] (Matthias)
* …

== Group photo ==

[[File:Fosdem-pgday-dev-meeting-2026.jpeg|728px]]

== Notes ==

* Review of the state of development processes and commitfests
** discussion about having subsystem maintainers, to enable contact points for patch submissions; could use tags in CF app to organize this
** discussion about being able to follow patches without signing up as reviewer
** straw poll: 9–0 in favor of having only one commitfest per development cycle, provided some mechanism of aging out stale patches earlier

* reduce the need for rebasing patches
** sources of conflicts?
*** #includes
*** new GUCs added at end of lists (might be obsolete)
*** typos fixes
*** pg_proc.dat
** idea: pg_xxx.dat.new during patch development
** maybe reorder pg_proc.dat to discourage everyone trying to add new entries in the same place
** collect more data about conflict causes from cfbot?

* dealing with large refactoring patches
** split patches into series, large mechanical changes could use "nocfbot-" prefix
** some large changes could be parked for after feature freeze; register under Open Items
** discussion about backpatching impact

* Planning for the upcoming beta period
** RMT (Tomas):
*** regular meetings every two weeks were useful
*** question about what "mid-beta" means
** packaging:
*** getting extension authors to update their extensions for a new major release is a challenge every year
*** unclear when extensions are expected to be ready, some extension authors don't want to put in the work too early
*** suggestion: extension authors should start their work after the June/July beta, extensions ready for August beta (would need to be documented)

* Commitfest website feedback and brainstorming
** forwarded some of the discussion above to CF app developer
** "follow patch" could be the same as current "subscribe to patch" without email
** access control to CF app needs to be refined, currently only former CF managers can edit certain things such as tags
** the newly deployed automoving functionality will run for the first time on 1st Feb., exciting

FOSDEM/PGDay 2026 Developer Meeting

2026-01-30T14:09:50Z

Petere: /* Notes */

See https://2026.fosdempgday.org/devmeeting/ for venue and other general information.

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="font-style:italic;background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:10
|Welcome and introductions

|-
|09:10–09:30
|Review of the state of development processes and commitfests

|-
|09:30–09:50
|Planning for the upcoming beta period

Schedule, packaging, [[Release Management Team]], etc.

|-
|09:50–10:10
|What can we do to reduce the need for rebasing patches? (Daniel)

In the past, OID conflicts was a common reason for patches no longer applying,
and since we started recommending to use OIDs from a set, that has drastically
reduced. We also ask patches to not bump catalog version, which also helps, but
it's worth discussing if we can do more. Can we make a separate
guc_parameters.dat for patches in flight to remove GUC collisions from rebase
conflicts? Are there other causes of trivial conflicts we can remove?

|-
|10:10–10:30
|How to deal with patches that generate a lot of refactoring? (Bertrand)

If a refactoring idea is worth it and would need to update say 200 files with
say 1000 changes, how do we proceed? It probably has to be split to ease the review and to avoid rebases for patches
waiting in the commitfest.

|- style="font-style:italic;background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|Development project status mini-presentations (5 min presentation + 5 min Q&A and changeover)

# Tomas: index prefetching
# Bertrand: Coccinelle
# Amit: batching executor
# <s>Jeff</s> (Peter): locale and collation work
# Peter: C11 and beyond adoption
# Bilal: Meson conversion
# Álvaro: repack
# Christoph: contributor badges

|- style="font-style:italic;background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–14:30
|Building the next generation of open source contributors, with Claire Giordano

(small presentation followed by discussion, inspired by this talk: https://fosdem.org/2026/schedule/event/JDZXFE-next-generation-contributors-lessons-from-postgres/)

|-
|14:30–15:00
|Dealing with near worthless/automated/synthetic patch submissions and reviews (Tomas)

|-
|15:00–15:25
|Commitfest website feedback and brainstorming

|-
|15:25–15:30
|Group photo

|- style="font-style:italic;background-color:lightgray;"
|15:30–16:00
|Tea

|-
|16:00–16:20
|Any other business

# Bruce: TDE
# Devrim: Distro support for the upcoming features

|-
|16:20–17:00
|Patch triage

(see below)

|}

(room available until 18:00)

== Participants ==

* Alexander Korotkov
* Álvaro Herrera
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Matthias van de Meent
* Nazir Bilal Yavuz
* Peter Eisentraut (organizer)
* Thomas Munro
* Tomas Vondra

== Patch triage ==

Attendees: Nominate patches to discuss during the patch triage section here. Additional patches can be added during the meeting, depending on the available time.

* https://commitfest.postgresql.org/patch/6050/ (Peter)
* [https://www.postgresql.org/message-id/CACG%3DezYeSygeb68tJVej9Qgji6k78V2reSqzh1_Y4P5GxCAGsw%40mail.gmail.com 64-bit xids] (Alexander)
* Logical Replication ([https://www.postgresql.org/message-id/CAMT0RQQx43yrCv5iB0A7H56VngTzw0gfJjVdwrtZ03ZMLWVk3g@mail.gmail.com "making tid and HOTness of UPDATE available to logical decoding plugins" etc.] (Matthias)
* …

== Group photo ==

[[File:Fosdem-pgday-dev-meeting-2026.jpeg|728px]]

== Notes ==

* Review of the state of development processes and commitfests
** discussion about having subsystem maintainers, to enable contact points for patch submissions; could use tags in CF app to organize this
** discussion about being able to follow patches without signing up as reviewer
** straw poll: 9–0 in favor of having only one commitfest per development cycle, provided some mechanism of aging out stale patches earlier

* reduce the need for rebasing patches
** sources of conflicts?
*** #includes
*** new GUCs added at end of lists (might be obsolete)
*** typos fixes
*** pg_proc.dat
** idea: pg_xxx.dat.new during patch development
** maybe reorder pg_proc.dat to discourage everyone trying to add new entries in the same place
** collect more data about conflict causes from cfbot?

* dealing with large refactoring patches
** split patches into series, large mechanical changes could use "nocfbot-" prefix
** some large changes could be parked for after feature freeze; register under Open Items
** discussion about backpatching impact

* Commitfest website feedback and brainstorming
** forwarded some of the discussion above to CF app developer
** "follow patch" could be the same as current "subscribe to patch" without email
** access control to CF app needs to be refined, currently only former CF managers can edit certain things such as tags
** the newly deployed automoving functionality will run for the first time on 1st Feb., exciting

FOSDEM/PGDay 2026 Developer Meeting

2026-01-30T14:06:01Z

Petere: /* Notes */

See https://2026.fosdempgday.org/devmeeting/ for venue and other general information.

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="font-style:italic;background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:10
|Welcome and introductions

|-
|09:10–09:30
|Review of the state of development processes and commitfests

|-
|09:30–09:50
|Planning for the upcoming beta period

Schedule, packaging, [[Release Management Team]], etc.

|-
|09:50–10:10
|What can we do to reduce the need for rebasing patches? (Daniel)

In the past, OID conflicts was a common reason for patches no longer applying,
and since we started recommending to use OIDs from a set, that has drastically
reduced. We also ask patches to not bump catalog version, which also helps, but
it's worth discussing if we can do more. Can we make a separate
guc_parameters.dat for patches in flight to remove GUC collisions from rebase
conflicts? Are there other causes of trivial conflicts we can remove?

|-
|10:10–10:30
|How to deal with patches that generate a lot of refactoring? (Bertrand)

If a refactoring idea is worth it and would need to update say 200 files with
say 1000 changes, how do we proceed? It probably has to be split to ease the review and to avoid rebases for patches
waiting in the commitfest.

|- style="font-style:italic;background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|Development project status mini-presentations (5 min presentation + 5 min Q&A and changeover)

# Tomas: index prefetching
# Bertrand: Coccinelle
# Amit: batching executor
# <s>Jeff</s> (Peter): locale and collation work
# Peter: C11 and beyond adoption
# Bilal: Meson conversion
# Álvaro: repack
# Christoph: contributor badges

|- style="font-style:italic;background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–14:30
|Building the next generation of open source contributors, with Claire Giordano

(small presentation followed by discussion, inspired by this talk: https://fosdem.org/2026/schedule/event/JDZXFE-next-generation-contributors-lessons-from-postgres/)

|-
|14:30–15:00
|Dealing with near worthless/automated/synthetic patch submissions and reviews (Tomas)

|-
|15:00–15:25
|Commitfest website feedback and brainstorming

|-
|15:25–15:30
|Group photo

|- style="font-style:italic;background-color:lightgray;"
|15:30–16:00
|Tea

|-
|16:00–16:20
|Any other business

# Bruce: TDE
# Devrim: Distro support for the upcoming features

|-
|16:20–17:00
|Patch triage

(see below)

|}

(room available until 18:00)

== Participants ==

* Alexander Korotkov
* Álvaro Herrera
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Matthias van de Meent
* Nazir Bilal Yavuz
* Peter Eisentraut (organizer)
* Thomas Munro
* Tomas Vondra

== Patch triage ==

Attendees: Nominate patches to discuss during the patch triage section here. Additional patches can be added during the meeting, depending on the available time.

* https://commitfest.postgresql.org/patch/6050/ (Peter)
* [https://www.postgresql.org/message-id/CACG%3DezYeSygeb68tJVej9Qgji6k78V2reSqzh1_Y4P5GxCAGsw%40mail.gmail.com 64-bit xids] (Alexander)
* Logical Replication ([https://www.postgresql.org/message-id/CAMT0RQQx43yrCv5iB0A7H56VngTzw0gfJjVdwrtZ03ZMLWVk3g@mail.gmail.com "making tid and HOTness of UPDATE available to logical decoding plugins" etc.] (Matthias)
* …

== Group photo ==

[[File:Fosdem-pgday-dev-meeting-2026.jpeg|728px]]

== Notes ==

* Review of the state of development processes and commitfests
** discussion about having subsystem maintainers, to enable contact points for patch submissions; could use tags in CF app to organize this
** discussion about being able to follow patches without signing up as reviewer
** straw poll: 9–0 in favor of having only one commitfest per development cycle, provided some mechanism of aging out stale patches earlier

* reduce the need for rebasing patches
** sources of conflicts?
*** #includes
*** new GUCs added at end of lists (might be obsolete)
*** typos fixes
*** pg_proc.dat
** idea: pg_xxx.dat.new during patch development
** maybe reorder pg_proc.dat to discourage everyone trying to add new entries in the same place
** collect more data about conflict causes from cfbot?

* Commitfest website feedback and brainstorming
** forwarded some of the discussion above to CF app developer
** "follow patch" could be the same as current "subscribe to patch" without email
** access control to CF app needs to be refined, currently only former CF managers can edit certain things such as tags
** the newly deployed automoving functionality will run for the first time on 1st Feb., exciting

FOSDEM/PGDay 2026 Developer Meeting

2026-01-30T13:07:36Z

Petere:

See https://2026.fosdempgday.org/devmeeting/ for venue and other general information.

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="font-style:italic;background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:10
|Welcome and introductions

|-
|09:10–09:30
|Review of the state of development processes and commitfests

|-
|09:30–09:50
|Planning for the upcoming beta period

Schedule, packaging, [[Release Management Team]], etc.

|-
|09:50–10:10
|What can we do to reduce the need for rebasing patches? (Daniel)

In the past, OID conflicts was a common reason for patches no longer applying,
and since we started recommending to use OIDs from a set, that has drastically
reduced. We also ask patches to not bump catalog version, which also helps, but
it's worth discussing if we can do more. Can we make a separate
guc_parameters.dat for patches in flight to remove GUC collisions from rebase
conflicts? Are there other causes of trivial conflicts we can remove?

|-
|10:10–10:30
|How to deal with patches that generate a lot of refactoring? (Bertrand)

If a refactoring idea is worth it and would need to update say 200 files with
say 1000 changes, how do we proceed? It probably has to be split to ease the review and to avoid rebases for patches
waiting in the commitfest.

|- style="font-style:italic;background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|Development project status mini-presentations (5 min presentation + 5 min Q&A and changeover)

# Tomas: index prefetching
# Bertrand: Coccinelle
# Amit: batching executor
# <s>Jeff</s> (Peter): locale and collation work
# Peter: C11 and beyond adoption
# Bilal: Meson conversion
# Álvaro: repack
# Christoph: contributor badges

|- style="font-style:italic;background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–14:30
|Building the next generation of open source contributors, with Claire Giordano

(small presentation followed by discussion, inspired by this talk: https://fosdem.org/2026/schedule/event/JDZXFE-next-generation-contributors-lessons-from-postgres/)

|-
|14:30–15:00
|Dealing with near worthless/automated/synthetic patch submissions and reviews (Tomas)

|-
|15:00–15:25
|Commitfest website feedback and brainstorming

|-
|15:25–15:30
|Group photo

|- style="font-style:italic;background-color:lightgray;"
|15:30–16:00
|Tea

|-
|16:00–16:20
|Any other business

# Bruce: TDE
# Devrim: Distro support for the upcoming features

|-
|16:20–17:00
|Patch triage

(see below)

|}

(room available until 18:00)

== Participants ==

* Alexander Korotkov
* Álvaro Herrera
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Matthias van de Meent
* Nazir Bilal Yavuz
* Peter Eisentraut (organizer)
* Thomas Munro
* Tomas Vondra

== Patch triage ==

Attendees: Nominate patches to discuss during the patch triage section here. Additional patches can be added during the meeting, depending on the available time.

* https://commitfest.postgresql.org/patch/6050/ (Peter)
* [https://www.postgresql.org/message-id/CACG%3DezYeSygeb68tJVej9Qgji6k78V2reSqzh1_Y4P5GxCAGsw%40mail.gmail.com 64-bit xids] (Alexander)
* Logical Replication ([https://www.postgresql.org/message-id/CAMT0RQQx43yrCv5iB0A7H56VngTzw0gfJjVdwrtZ03ZMLWVk3g@mail.gmail.com "making tid and HOTness of UPDATE available to logical decoding plugins" etc.] (Matthias)
* …

== Group photo ==

[[File:Fosdem-pgday-dev-meeting-2026.jpeg|728px]]

== Notes ==

* Review of the state of development processes and commitfests
** discussion about having subsystem maintainers, to enable contact points for patch submissions; could use tags in CF app to organize this
** discussion about being able to follow patches without signing up as reviewer
** straw poll: 9–0 in favor of having only one commitfest per development cycle, provided some mechanism of aging out stale patches earlier

* Commitfest website feedback and brainstorming
** forwarded some of the discussion above to CF app developer
** "follow patch" could be the same as current "subscribe to patch" without email
** access control to CF app needs to be refined, currently only former CF managers can edit certain things such as tags
** the newly deployed automoving functionality will run for the first time on 1st Feb., exciting

FOSDEM/PGDay 2026 Developer Meeting

2026-01-30T12:57:29Z

Petere:

File:Fosdem-pgday-dev-meeting-2026.jpeg

2026-01-30T12:54:19Z

Petere: FOSDEM PGDay 2026 developer meeting group photo

== Summary ==
FOSDEM PGDay 2026 developer meeting group photo

FOSDEM/PGDay 2026 Developer Meeting

2026-01-29T12:28:29Z

Petere: /* Schedule */

FOSDEM/PGDay 2026 Developer Meeting

2026-01-29T09:59:08Z

Petere: /* Schedule */

FOSDEM/PGDay 2026 Developer Meeting

2026-01-28T07:55:12Z

Petere: /* Participants */

FOSDEM/PGDay 2026 Developer Meeting

2026-01-27T08:59:28Z

Petere: /* Participants */

FOSDEM/PGDay 2026 Developer Meeting

2026-01-18T11:15:18Z

Petere:

FOSDEM/PGDay 2026 Developer Meeting

2026-01-16T20:16:49Z

Petere: /* Schedule */

https://2026.fosdempgday.org/devmeeting/

currently being planned

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="font-style:italic;background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:10
|Welcome and introductions

|-
|09:10–09:30
|Review of the state of development processes and commitfests

|-
|09:30–09:50
|Planning for the upcoming beta period

Schedule, packaging, [[Release Management Team]], etc.

|-
|09:50–10:10
|What can we do to reduce the need for rebasing patches? (Daniel)

In the past, OID conflicts was a common reason for patches no longer applying,
and since we started recommending to use OIDs from a set, that has drastically
reduced. We also ask patches to not bump catalog version, which also helps, but
it's worth discussing if we can do more. Can we make a separate
guc_parameters.dat for patches in flight to remove GUC collisions from rebase
conflicts? Are there other causes of trivial conflicts we can remove?

|-
|10:10–10:30
|How to deal with patches that generate a lot of refactoring? (Bertrand)

If a refactoring idea is worth it and would need to update say 200 files with
say 1000 changes, how do we proceed? It probably has to be split to ease the review and to avoid rebases for patches
waiting in the commitfest.

|- style="font-style:italic;background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|Development project status mini-presentations (5 min presentation + 5 min Q&A and changeover)

# Tomas: index prefetching
# Bertrand: Coccinelle
# Amit: batching executor
# Jeff: locale and collation work
# Peter: C11 and beyond adoption
# Bilal: Meson conversion
# Álvaro: repack
# Nathan: SIMD

|- style="font-style:italic;background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–14:30
|Building the next generation of open source contributors, with Claire Giordano

(small presentation followed by discussion, inspired by this talk: https://fosdem.org/2026/schedule/event/JDZXFE-next-generation-contributors-lessons-from-postgres/)

|-
|14:30–15:00
|Dealing with near worthless/automated/synthetic patch submissions and reviews (Tomas)

|-
|15:00–15:30
|Commitfest website feedback and brainstorming

|- style="font-style:italic;background-color:lightgray;"
|15:30–16:00
|Tea

|-
|16:00–17:00
|Patch triage

|}

(room available until 18:00)

== Participants ==

* Alexander Korotkov
* Álvaro Herrera
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jeff Davis
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Matthias van de Meent
* Nathan Bossart
* Nazir Bilal Yavuz
* Peter Eisentraut (organizer)
* Thomas Munro
* Tomas Vondra

FOSDEM/PGDay 2026 Developer Meeting

2026-01-15T14:46:41Z

Petere: /* Participants */

FOSDEM/PGDay 2026 Developer Meeting

2026-01-15T14:37:58Z

Petere: /* Schedule */

FOSDEM/PGDay 2026 Developer Meeting

2026-01-15T14:29:57Z

Petere: /* Schedule */

FOSDEM/PGDay 2026 Developer Meeting

2026-01-12T21:17:48Z

Petere: /* Schedule */

FOSDEM/PGDay 2026 Developer Meeting

2026-01-12T11:07:35Z

Petere: /* Participants */

https://2026.fosdempgday.org/devmeeting/

currently being planned

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:15
|Welcome and Introductions

|-
|09:15–10:30
|engaging content

|- style="background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|engaging content

|- style="background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–15:30
|engaging content

|- style="background-color:lightgray;"
|15:30–16:00
|Tea

|- style="background-color:white;"
|16:00–17:00
|still more content

|}

(room available until 18:00)

== Participants ==

(confirmed as of 2026-01-12)

* Alexander Korotkov
* Álvaro Herrera
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jeff Davis
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Matthias van de Meent
* Nathan Bossart
* Nazir Bilal Yavuz
* Peter Eisentraut
* Thomas Munro
* Tomas Vondra

FOSDEM/PGDay 2026 Developer Meeting

2026-01-12T11:07:15Z

Petere: /* Participants */

https://2026.fosdempgday.org/devmeeting/

currently being planned

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:15
|Welcome and Introductions

|-
|09:15–10:30
|engaging content

|- style="background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|engaging content

|- style="background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–15:30
|engaging content

|- style="background-color:lightgray;"
|15:30–16:00
|Tea

|- style="background-color:white;"
|16:00–17:00
|still more content

|}

(room available until 18:00)

== Participants ==

(confirmed as of 2026-01-06)

* Alexander Korotkov
* Álvaro Herrera
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jeff Davis
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Matthias van de Meent
* Nathan Bossart
* Nazir Bilal Yavuz
* Peter Eisentraut
* Thomas Munro
* Tomas Vondra

FOSDEM/PGDay 2026 Developer Meeting

2026-01-12T07:28:44Z

Petere: /* Schedule */

https://2026.fosdempgday.org/devmeeting/

currently being planned

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:15
|Welcome and Introductions

|-
|09:15–10:30
|engaging content

|- style="background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|engaging content

|- style="background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–15:30
|engaging content

|- style="background-color:lightgray;"
|15:30–16:00
|Tea

|- style="background-color:white;"
|16:00–17:00
|still more content

|}

(room available until 18:00)

== Participants ==

(confirmed as of 2026-01-06)

* Alexander Korotkov
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jeff Davis
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Matthias van de Meent
* Nathan Bossart
* Nazir Bilal Yavuz
* Peter Eisentraut
* Thomas Munro
* Tomas Vondra

FOSDEM/PGDay 2026 Developer Meeting

2026-01-06T18:18:56Z

Petere: /* Participants */

https://2026.fosdempgday.org/devmeeting/

currently being planned

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:15
|Welcome and Introductions

|-
|09:15–10:30
|engaging content

|- style="background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|engaging content

|- style="background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–15:30
|engaging content

|- style="background-color:lightgray;"
|15:30–16:00
|Tea

|- style="background-color:white;"
|16:00–18:00
|still more content

|}

== Participants ==

(confirmed as of 2026-01-06)

* Alexander Korotkov
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jeff Davis
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Matthias van de Meent
* Nathan Bossart
* Nazir Bilal Yavuz
* Peter Eisentraut
* Thomas Munro
* Tomas Vondra

FOSDEM/PGDay 2026 Developer Meeting

2025-12-29T07:52:27Z

Petere: /* Participants */

https://2026.fosdempgday.org/devmeeting/

currently being planned

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:15
|Welcome and Introductions

|-
|09:15–10:30
|engaging content

|- style="background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|engaging content

|- style="background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–15:30
|engaging content

|- style="background-color:lightgray;"
|15:30–16:00
|Tea

|- style="background-color:white;"
|16:00–18:00
|still more content

|}

== Participants ==

(confirmed as of 2025-12-29)

* Alexander Korotkov
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jeff Davis
* Jelte Fennema-Nio (afternoon)
* Joe Conway
* Magnus Hagander
* Nathan Bossart
* Nazir Bilal Yavuz
* Peter Eisentraut
* Thomas Munro
* Tomas Vondra

FOSDEM/PGDay 2026 Developer Meeting

2025-12-15T13:20:29Z

Petere: add particpants

https://2026.fosdempgday.org/devmeeting/

currently being planned

== Schedule ==
{| border="1" cellpadding="4" cellspacing="0"
!Time
!Topic

|- style="background-color:lightgray;"
|08:00–09:00
|Coffee (not breakfast)

|-
|09:00–09:15
|Welcome and Introductions

|-
|09:15–10:30
|engaging content

|- style="background-color:lightgray;"
|10:30–11:00
|Coffee

|-
|11:00–12:30
|engaging content

|- style="background-color:lightgray;"
|12:30–13:30
|Lunch

|-
|13:30–15:30
|engaging content

|- style="background-color:lightgray;"
|15:30–16:00
|Tea

|- style="background-color:white;"
|16:00–18:00
|still more content

|}

== Participants ==

(confirmed as of 2025-12-15)

* Alexander Korotkov
* Amit Langote
* Bertrand Drouvot
* Bruce Momjian
* Christoph Berg
* Daniel Gustafsson
* Dave Page
* Devrim Gündüz
* Jeff Davis
* Joe Conway
* Magnus Hagander
* Nathan Bossart
* Nazir Bilal Yavuz
* Peter Eisentraut
* Thomas Munro
* Tomas Vondra

FOSDEM/PGDay 2026 Developer Meeting

2025-12-15T13:13:48Z

Petere: template schedule

PostgreSQL 18 Open Items

2025-11-04T13:50:20Z

Petere: /* Older bugs affecting stable branches */

== Open Issues ==

'''NOTE''': Please place new open items at the end of the list.

'''NOTE''': If known, please list the Owner of the open item.

* {{messageLink|8af20905-2cc5-4f1a-b2a2-ca59882aa880%40vondra.me|2=Performance degradation with glibc malloc due to increased catcache memory usage after the btree skip scan patch}}
** Testing showed that with {{PgCommitURL|92fe23d93aa}} the standard catalogs don't leave enough memory in GLIBC's default marginal memory for query planning and execution. This causes glibc to extend and truncate the sbrk area with every executed query, causing high rates of OS-level allocations, page faults, and thus significantly decreasing performance.
** Though technically an allocator issue, users may not know (how) to configure glibc's allocator tunables, and so may not get optimal performance.
** Two approaches to fixing the increased usage of memory by index caches:
*** Peter G. has a patch to remove BTOPTIONS_PROC (returning BTNProcs back to pg17's 5, from 6);
*** Matthias has a patch to change the IndexAmRoutine* returned by index am's handler_function to a const pointer into static allocations, from a dynamic allocation in memory contexts.

== Decisions to Recheck Mid-Beta ==

(none)

== Older bugs affecting stable branches ==

=== Live issues ===

* {{messageLink|1=CAH2-Wz%3DPqOziyRSrnN5jAtfXWXY7-BJcHz9S355LH8Dt%3D5qxWQ@mail.gmail.com|2=Incorrect results for (SP-)GIST index-only scans}}
** GIST and SP-GIST indexes hold tuples in memory after releasing the pin on the page, but before returning them to the executor. This allows VACUUM to concurrently clean up any dead tuples from the page's results, and mark the heap pages that held the dead tuples as ALL_VISIBLE, breaking index-only scans.
** Comprehensive fix: {{messageLink|1=CAEze2WgnHJF66BtviDFNCPy26gLrb%2Btfns-Bi62DBfReH0-UCg%40mail.gmail.com|2=Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?}}
** Suggested fix for backpatching, 17-: {{messageLink|1=CAEze2WgH13m=MDST58KLo-NkZpbwBEt4xNWcgtghWBwRj3J0+A%40mail.gmail.com|2=<nowiki>[SP-]GiST IOS visibility bug</nowiki>}}

* {{messageLink|CACJufxGKWZ3WWC7m_F4v-1X7NP2%3D-eU8hjo37P8RfEcdcVzUTg%40mail.gmail.com|2=generation expression node collation inaccurate}}
** generation expression node collation does not match the corresponding data type's collation

* {{messageLink|CACJufxG5wLiATocRTaC%3Dz%2Bkw4mUaasC-50%2Bq9K%3DfOdAr3%3DOGRw%40mail.gmail.com|2=unsafe change individual column when partition key have wholerow reference}}
** we should disallow alter individual column if partition key contains wholerow reference

=== Fixed issues ===

* {{messageLink|873c33c5-ef9e-41f6-80b2-2f5e11869f1c%40garret.ru|Incorrect results for bitmap heap scan.}}
** Certain Bitmap Heap scans only test the visibility map before returning tuples. This can conflict with VACUUM removing tuples, thus causing more tuples to be returned from the scan than what are actually visible.
** Commit: {{PgCommitURL|459e7bf8e2}}

* {{messageLink|CACJufxG59tip2%2B9h%3DrEv-ykOFjt0cbsPVchhi0RTij8bABBA0Q%40mail.gmail.com|bug in stored generated column over domain with constraints.}}
** Commit: {{PgCommitURL|7c872849407}}

* {{messageLink|aBEV3AQwhAMm0v2k%40nathan|2=unsafe access of some catalogs' TOAST tables}}
** We should consider removing pg_replication_origin's TOAST table in v18 to fix a few places that don't set up a snapshot before potentially accessing TOASTed data.
** Commit: {{PgCommitURL|16bf24e0e4}}

* [https://www.postgresql.org/message-id/flat/20250626.155608.568829483879866256.ishii@postgresql.org document StartupMessage correctly for protocol 3.2]
** Commit: {{PgCommitURL|4cff01c4a3}}

* {{messageLink|CACJufxFSC0mcQ82bSk58sO-WJY4P-o4N6RD2M0D%3DDD_u_6EzdQ%40mail.gmail.com|2=create domain can create two not-null constraints}}
** create domain should only create one not-null constraint. This issue exists in PG17 and PG18
** Commit: {{PgCommitURL|647cffd2f3}}

* {{messageLink|CACJufxF-0bqVR%3Dj4jonS6N2Ka6hHUpFyu3_3TWKNhOW_4yFSSg%40mail.gmail.com|2=pg_dump does dump domain notnull constraint comments}}
** pg_dump need dump these domain not null comments. This issue only exist in PG17 and PG18
** Commit: {{PgCommitURL|da71717f0a}}

* {{messageLink|CACJufxF%3DWDGthXSAQr9thYUsfx_1_t9E6N8tE3B8EqXcVoVfQw%40mail.gmail.com|2=generated column being included in partition key expression}}
** generated column can not be included in partition key expression, some corner case it will be included
** Commit: {{PgCommitURL|ba99c9491c4}}

== Non-bugs ==

* {{messageLink|2045026.1743801143@sss.pgh.pa.us|Fundamental scheduling bug in parallel restore of partitioned tables}}
** Current belief is that this is only a performance hazard, and hence not worth breaking feature freeze to fix. We can take it up in v19 instead.

* {{messageLink|aFzdVCWEhbUgn91k@paquier.xyz|join_search_hook broken by self-join elimination}}
** Yet we only know it affects pg_hint_plan, but enable_self_join_elimination GUC provides a workaround.
** Commit: {{PgCommitURL|fc069a3a6319}}

== Resolved Issues ==

=== resolved before 18rc1 ===

* {{messageLink|flat/CAKAnmmKwiMHik5AHmBEdf5vqzbOBbcwEPHo4-PioWeAbzwcTOQ@mail.gmail.com|Enable data checksums by default}}
** Commit: {{PgCommitURL|04bec894a0}}
** Data checksums have been enabled by default. pg_upgrade cannot upgrade between non-checksum and checksum instances, so some additional steps are required by the user. Check whether the upgrade experience is tolerable and sufficiently documented. See the following list of threads that might be enhancing the end user experience:
*** {{messageLink|flat/E07A611B-9CF3-4FDB-8CE8-A221E39040EC%40yesql.se|Changing the state of data checksums in a running cluster}}
** Also, a thread complaining about the extremely visible performance regression that results:
*** {{messageLink|flat/CADE6Lvh62KopfpyScY-sMvLQE6Y5BBfAnt2wV-nsvZLetF+j6g@mail.gmail.com|Possible regression in PG18 beta1}}
** {{messageLink|flat/941f0190-e3c6-4622-9ac7-c04e936e5fdb@vondra.me|strange perf regression with data checksums}}
** Owner: Peter Eisentraut?
** result: No clear proposals to change the default. We're likely keeping checksums enabled.

* [https://www.postgresql.org/message-id/flat/20250617.101056.1437027795118961504.ishii@postgresql.org handle servers that don't send BackendKeyData gracefully]
** Owner: Heikki Linnakangas
** Fixed by: {{PgCommitURL|f6f0542266f}}, {{PgCommitURL|e411a8d25a}}, {{PgCommitURL|807ee417e5}}

* {{messageLink|20250809222338.cc.nmisch@google.com|"cannot take query snapshot during logical decoding" incompatible w/ pglogical row_filter}}
** Owner: Heikki Linnakangas
** Commit: {{PgCommitURL|1585ff7387}}
** Fixed by: {{PgCommitURL|50f770c3d9}}

* {{messageLink|20250820104226.8ba51e43164cd590b863ce41%40sraoss.co.jp|Don't treat virtual generated columns as missing statistics in vacuumdb --missing-stats-only}}
** Owner: Nathan Bossart
** Fixed by: {{PgCommitURL|b63952a781}}

* {{messageLink|CAHGQGwHh43suEfss1wvBsk7vqiou%3DUY0zcy8HGyE5hBp%2BHZ7SQ%40mail.gmail.com|vacuumdb --missing-stats-only and permission issue}}
** Owner: Nathan Bossart
** Fixed by: {{PgCommitURL|984d7165dd}}

* {{messageLink|CA%2BhUKGJfOGBf55oLsgvv1PZSuJm1%2BR8yFbVHsP3VnEu%3DdOqayQ%40mail.gmail.com|2=VM corruption on standby}}
** Owner: Alexander Korotkov
** likely caused by "Get rid of WALBufMappingLock" {{PgCommitURL|bc22dc0e0ddc2dcb6043a732415019cc6b6bf683}}
** Fixed by: {{PgCommitURL|c13070a27b}}

* {{messageLink|20241125012400.6f.nmisch@google.com|"object locking for GRANT/REVOKE" removed a comment about a failure mode it didn't change, and it reduced test coverage}}
** Owner: Peter Eisentraut
** Commit: {{PgCommitURL|d31bbfb}}
** Fixed by: {{PgCommitURL|e36fa9319b}}, {{PgCommitURL|310d04169a}}

* {{messageLink|1fd1a421-4609-4d46-a1af-ab74d5de504a%40tantorlabs.ru|Remove self joins causes 'variable not found in subplan target lists' error}}
** Owner: Tom Lane
** Dates to {{PgCommitURL|a3179ab692be4314d5ee5cd56598976c487d5ef2}}, so it's not actually related to remove-self-joins patch
** Fixed by: {{PgCommitURL|3aee6283709}}, {{PgCommitURL|b8a1bdc458e}}

* {{messageLink|flat/653f3b84-fc87-45a7-9a0c-bfb4fcab3e7d%40eisentraut.org|fixing tsearch locale support}}
** Commit: {{PgCommitURL|fb1a18810f0}}
** Text search locale support has been updated and integrated into the common locale framework. Possible upgrade issues should probably at least be noted in the release notes.
** Owner: Peter Eisentraut?
** Fixed by: {{PgCommitURL|d1073c3b4cc}}

=== resolved before 18beta3 ===

* [https://www.postgresql.org/message-id/flat/08129593-6f3c-4fb9-94b7-5aa2eefb99b0%40oss.nttdata.com pg_dumpall dumps global objects with --statistics-only or --no-schema]
** Owner: Jeff Davis
** Fixed by: {{PgCommitURL|973caf7291}}

* [https://www.postgresql.org/message-id/flat/7cc52488-f876-4ad3-affd-6e4b0ef0cb09%40eisentraut.org decide on new pg_dump flags and whether stats should be enabled by default]
** Owner: Jeff Davis
** Fixed by: {{PgCommitURL|a3e8dc1438}}

* [https://www.postgresql.org/message-id/eb224uegsga2hgq7dfq3ps5cduhpqej7ir2hjxzzozjthrekx5%40dysei6buqthe Custom pgstat support performance regression for simple queries]
** Owner: Michael Paquier
** Commit: {{PgCommitURL|fc415edf8ca8}}
** Fixed by: {{PgCommitURL|ac000fca743e}} and {{PgCommitURL|793928c2d5ac}}

* {{messageLink|87qzyghw2x.fsf@wibble.ilmari.org|tab completion for ALTER DATABASE/ROLE/USER ... RESET}}
** Owner: Tomas Vondra
** Commit: {{PgCommitURL|9df8727c5067}} {{PgCommitURL|c407d5426b87}}
** Fixed by: {{PgCommitURL|dbf5a83d4650}} and {{PgCommitURL|ca09ef3a6aa6}}

* {{messageLink|20250708212819.09.nmisch@google.com|non-text mode for pg_dumpall: DROP, options ignored, lexing, if-not-exists, etc.}}
** Owner: Andrew Dunstan
** Commit: {{PgCommitURL|1495eff}}
** Fixed by: {{PgCommitURL|4a9ee867bff}} and {{PgCommitURL|3a954813a0f}}

* {{messageLink|CAOYmi%2BnGstyp4OyL8SFCm3dtkBzNJqGwL7xYhe85%3Dj2hhaXAMw%40mail.gmail.com|Unnecessary CPU usage with OAuth on Mac and BSD}}
** [https://www.postgresql.org/message-id/CAOYmi%2BnDZxJHaWj9_jRSyf8uMToCADAmOfJEggsKW-kY7aUwHA%40mail.gmail.com OAuth: fix performance bug with stuck multiplexer events]
** Owner: Jacob Champion
** Fixed-by: {{PgCommitURL|ff5b082}}, {{PgCommitURL|3d9c034}}, {{PgCommitURL|1749a12}}, {{PgCommitURL|3e31166}}, {{PgCommitURL|1443b6c}}, {{PgCommitURL|ebaaf38}}

* [https://www.postgresql.org/message-id/19006-80fcaaf69000377e@postgresql.org Assert(BufferIsPinned) in BufferGetBlockNumber() is triggered for forwarded buffer]
** Commit: {{PgCommitURL|b421223172a2}}

* Revisit libpq-oauth naming/ABI
** Commit: {{PgCommitURL|b0635bfda}}
** The libpq-oauth module relies on libpq internals, so it'll be renamed every major release to avoid ABI incompatibilities. This reduces developer load at the expense of {{messageLink|CAOYmi%2B%3Dcs%2BgDTAH0L%2B3JzpRLeHPOXDQxu7MOfsbjah9SkAP_kw%40mail.gmail.com|packager pain}}. Is that acceptable?
** Owner: Jacob Champion
** Resolution: {{messageLink|CAOYmi%2Bm5L%3D-S8QuZgLcSdHyXreVDCVr2NBbCZVcdVzE8B2y5Xg%40mail.gmail.com|No objections raised.}}

=== resolved before 18beta2 ===

* queryId constant squashing does not support prepared statements
** Owner: Alvaro Herrera
** Commit: {{PgCommitURL|62d712ecfd94}}
** {{messageLink|CAA5RZ0tRXoPG2y6bMgBCWNDt0Tn%3DunRerbzYM%3DoW0syi1%3DC1OA%40mail.gmail.com|bug report}}
** Fixed by: {{PgCommitURL|c2da1a5d6325a92d834c9cb036f65d362e4bfc3e}}

* [https://www.postgresql.org/message-id/26983.1748418675@localhost Foreign key validation failure in 18beta1]
** Owner: Alvaro Herrera
** Commit: {{PgCommitURL|b663b9436e7509b5e73c8c372539f067cd6e66c1}}
** Fixed by: {{PgCommitURL|cc733ed164c5b57fdf34d16e4cc8e9bbdc171699}}

* [https://postgr.es/m/3eb40b3e-45c7-426a-b7f8-81f7d05a9b53@oss.nttdata.com pg_get_process_memory_contexts can cause the target session to error out]
** Defect in commit 042a66291b04f473cbc72f95f07438abd75ae3a9
** Owner: Daniel Gustafsson
** {{messageLink|65EB9E45-BD41-4DA7-A689-7A358CF7826F@yesql.se|Patch}}
** Commit: {{PgCommitURL|fb844b9f06568a}}

* [https://postgr.es/m/605328.1747710381@sss.pgh.pa.us issues with generic plans and "initial" pruning]
** Commit: {{PgCommitURL|525392d57}}
** Owner: Amit Langote
** Fixed by: {{PgCommitURL|1722d5eb05d8e5d2e064cd1798abcae4f296ca9d}}

* Refactoring for ChangeVarNodesExtended()
** Owner: Alexander Korotkov
** Commit: {{PgCommitURL|fc069a3a6319b5bf40d2f0f1efceae1c9b7a68a8}}
** {{messageLink|CAMbWs49PE3CvnV8vrQ0Dr%3DHqgZZmX0tdNbzVNJxqc8yg-8kDQQ%40mail.gmail.com|Some problems regarding the self-join elimination code}}
** Fixed by: {{PgCommitURL|ab42d643c14509cf1345588f55d798284b11a91e}}

* Clean up injection point tests in AIO code
** Owner: Andres Freund (note from Michael Paquier: I'm OK to handle this one).
** Commit: {{PgCommitURL|93bc3d75d8e1}}
** {{messageLink|Z_y9TtnXubvYAApS@paquier.xyz|Support for runtime parameters in injection points, for AIO tests}}
** Fixed by: {{PgCommitURL|371f2db8b05e}}, {{PgCommitURL|36e5fda63260}}, {{PgCommitURL|c259ba881c10}}

* [https://postgr.es/m/18923-e79273f87c6bed69%40postgresql.org pg_dump 18beta1 fails to process complex table names]
** Commit: {{PgCommitURL|9c02e3a986}}
** Owner: Nathan Bossart
** Fixed by: {{PgCommitURL|a6060f1cbe}}

* Regression in statement locations with nested statements
** Commit: {{PgCommitURL|499edb09741b}}
** Owner: Michael Paquier
** [https://postgr.es/m/844a3b38-bbf1-4fb2-9fd6-f58c35c09917@pgbackrest.org bug report]
** Fixed by: {{PgCommitURL|06450c7b8c70}}

* [https://postgr.es/m/CAAeiqZ0o2p4SX5_xPcuAbbsmXjg6MJLNuPYSLUjC%3DWh-VeW64A%40mail.gmail.com incorrect reltuples after upgrade from <v14]
** Commit: {{PgCommitURL|1fd1bd8710}}
** Owner: Nathan Bossart
** Fixed by: {{PgCommitURL|5d6eac80cd}}

* [https://www.postgresql.org/message-id/CAD21AoConf6tkVCv-=JhQJj56kYsDwo4jG5+WqgT+ukSkYomSQ@mail.gmail.com assert failure during eager scanning]
** Commit: {{PgCommitURL|052026c9b903}}
** Owner: Melanie Plageman
** Fixed by: {{PgCommitURL|4c08ecd1618}}

* Prevent stack overflow in OAuth parsers
** Owner: Jacob Champion
** Commit: {{PgCommitURL|b3f0be788a}}
** {{messageLink|CAOYmi%2Bm71aRUEi0oQE9ciBnBS8xVtMn3CifaPu2kmJzUfhOZgA%40mail.gmail.com|Patch/discussion}}
** Fixed by: {{PgCommitURL|cbc8fd0c9}}

* [https://www.postgresql.org/message-id/aCvzJNwetyEI3Sgo%40paquier.xyz Redefine plan ID as int64 rather than uint64]
** The same problem applies to the query ID, but it is an older problem. The plan ID is new in v18.
** Commit: {{PgCommitURL|2a0cd38da5cc}}
** Owner: Michael Paquier
** Fixed by: {{PgCommitURL|e050af28686e}}

* Enable statistics in pg_dump by default (Jeff Davis)?
** {{messageLink|1=CAKAnmmKCgnqcd3x4Z+5yXsY7urpDS6D_NZG7pr=DYD=LHt5X4g@mail.gmail.com|2=Greg Sabino Mullane}}
** {{messageLink|1=CA+TgmoYGuEC=E4TbomRyqO8+Uav=90G0dYXw=rA1d5UmRB76Yg@mail.gmail.com|2=Robert Haas}}
** decision was opt-in for pg_dump[all] and opt-out for pg_upgrade/pg_restore
** Fixed by: {{PgCommitURL|34eb2a80d5}}

* [https://www.postgresql.org/message-id/flat/18944-8a926c30f68387dd%40postgresql.org Assertion Failure in psql with idle_session_timeout set]
** Owner: Michael Paquier
** Commit: {{PgCommitURL|41625ab8ea3d}}
** Fixed by: {{PgCommitURL|7f3381c7ee66}}

* [https://www.postgresql.org/message-id/18920-b350b1c0a30af006@postgresql.org LOAD '$libdir/plugins' no longer works in 18beta1]
** Owner: Peter Eisentraut
** Commit: {{PgCommitURL|4f7f7b037585}}
** Fixed by: {{PgCommitURL|f777d77387}}

* {{messageLink|20250415155850.9b.nmisch@google.com|Trademark risk in new test}}
** Owner: Tom Lane
** Commit: {{PgCommitURL|01463e1}}
** Fixed by: {{PgCommitURL|4b05ebf095}}

* [https://postgr.es/m/18947-cdd2668beffe02bf@postgresql.org failed Assert("len_to_wrt >= 0") in pg_stat_statements]
** Owner: Michael Paquier
** Commit: {{PgCommitURL|499edb09741b}}
** Fixed by: {{PgCommitURL|f85f6ab051b7}}

* [https://postgr.es/m/CAE7r3MJ611B9TE=YqBBncewp7-k64VWs+sjk7XF6fJUX77uFBA@mail.gmail.com Improvements in GIN amcheck]
** Commit: {{PgCommitURL|14ffaece0fb53fed8ddbc46d2b353e1c4834863a}}
** Owner: Tomas Vondra
** Fixed by: {{PgCommitURL|0cf205e122ae0fe9333ccf843c2269f13ddc32fc}}

* {{messageLink|20250706161319.c1.nmisch@google.com|Remove PQservice()}}
** Owner: Michael Paquier
** Commit: {{PgCommitURL|4b99fed75}}
** Fixed by: {{PgCommitURL|fef6da9}}

* [https://www.postgresql.org/message-id/CAK_s-G2Q7de8Q0qOYUR=_CTB5FzzVBm5iZjOp+meVWpMpmfO0w@mail.gmail.com virtual generated columns are unsafe if superuser selects]
** Owner: Peter Eisentraut
** Fixed by: {{PgCommitURL|0cd69b3d7ef}}

* {{messageLink|1500090.1745443021%40sss.pgh.pa.us|Non-reproducible AIO failure}}
** Owner: Andres Freund
** Partially fixed by: {{PgCommitURL|e9a3615a522}}, remaining issue is not reproducible

=== resolved before 18beta1 ===

* Fix guidance for running vacuumdb after pg_upgrade
** Owner: Nathan Bossart
** Commit: {{PgCommitURL|c9d502eb68}}
** {{messageLink|aAfxfKC82B9NvJDj%40msg.df7cb.de|pgsql: Update guidance for running vacuumdb after pg_upgrade.}}
** Fixed by: {{PgCommitURL|d5f1b6a75b}}, {{PgCommitURL|9879105024}}

* Not null not valid: pg_dump output is inconsistent on table inheritence tables
** Owner: Álvaro Herrera
** Commit: {{PgCommitURL|a379061a22a8fdf421e1a457cc6af8503def6252}}
** {{messageLink|CACJufxGHNNMc0E2JphUqJMzD3%3DbwRSuAEVBF5ekgkG8uY0Q3hg%40mail.gmail.com| pg_dump not null not valid is wrong}}
** Fixed by: {{PgCommitURL|0e13b13d26e}}

* Difference in statistics on original and restored database
** Owner: Ashutosh Bapat
** Commit: {{PgCommitURL|172259afb5}}
** {{messageLink|1=CAExHW5sFOgcUkVtZ8=QCAE+jv=sbNdBKq0xZCNJTh7019ZM+CQ@mail.gmail.com|2=Original report}}
** {{messageLink|1=CAExHW5uX1oH3f9WNGJf0E-0C9JFO20EryT0nMN42gfia5rkQLA@mail.gmail.com|2=Fix discussion}}
** Once this issue is fixed, we need to enable dumping statistics and comparing them in pg_upgrade/002_pg_upgrade.pl. The patch for the same is posted in the thread.

* Use-after-free with stats_fetch_consistency = snapshot and pg_stat_get_backend_wal()
** Owner: Michael Paquier
** Commit: {{PgCommitURL|76def4cdd}}
** {{messageLink|f1788cc0-253a-4a3a-aee0-1b8ab9538736@gmail.com|Details of report}}
** Fixed by: {{PgCommitURL|3191a593d6de}}

* Performance regression in SQL-language functions
** Owner: Tom Lane
** Commit: {{PgCommitURL|0dca5d68d}}
** {{messageLink|1112592.1744572204@sss.pgh.pa.us|Performance issues with v18 SQL-language-function changes}}
** Fixed by: {{PgCommitURL|0400ae4a6}} and four preceding patches

* Memory mismanagement leads to infinite loop in walsender
** Owner: Tom Lane
** Commit: {{PgCommitURL|1afe31f03}}
** {{messageLink|CAO6_XqoJA7-_G6t7Uqe5nWF3nj+QBGn4F6Ptp%3DrUGDr0zo+KvA%40mail.gmail.com|bug report}}
** Fixed by: {{PgCommitURL|80b727eb9}}

* Not-null-in-pg_constraint changes cause parallel restore to deadlock
** Owner: Alvaro Herrera
** Commit: {{PgCommitURL|14e87ffa5c543b5f30ead7413084c25f7735039f}}
** {{messageLink|1280408.1744650810@sss.pgh.pa.us|Re: not null constraints, again}}
** Fixed by: {{PgCommitURL|11ff192b5}}

* Avoid core dump in pgstat_read_statsfile()
** Owner: Michael Paquier
** Commit: {{PgCommitURL|7949d9594582}}
** {{messageLink|aAieZAvM+K1d89R2@ip-10-97-1-34.eu-west-3.compute.internal|Avoid core dump in pgstat_read_statsfile()}}
** Fixed by: {{PgCommitURL|923ae50cf559}}

* Assertion failure in discardAbortedPipelineResults() with psql's pipeline mode
** Owner: Michael Paquier
** Commit :{{PgCommitURL|2cce0fe440fb}}
** {{messageLink|ebf6ce77-b180-4d6b-8eab-71f641499ddf@postgrespro.ru|bug report}}
** Fixed by: {{PgCommitURL|3631612eae9c}}

* Use extended stats for precise estimation of bucket size in hash join
** Owner: Alexander Korotkov
** Commit: {{PgCommitURL|6bb6a62f3cc45624c601d5270673a17447734629}}
** {{messageLink|18885-da51324078588253@postgresql.org|ERROR: corrupt MVNDistinct entry - 2}}
** Fixed by: {{PgCommitURL|9f404d7922e8831dc49bfa225530ba5309900e4e}}

* Bugs in self-join elimination
** Owner: Alexander Korotkov
** Commit: {{PgCommitURL|fc069a3a6319b5bf40d2f0f1efceae1c9b7a68a8}}
** {{messageLink|CAMbWs49PE3CvnV8vrQ0Dr%3DHqgZZmX0tdNbzVNJxqc8yg-8kDQQ%40mail.gmail.com|Some problems regarding the self-join elimination code}}
** {{messageLink|CAPpHfdtTxSs%2Bt8PXjJ_EC5roaQRLPyxt71M%3DAJvrGjYFC-wK5g%40mail.gmail.com|ERROR: too late to create a new PlaceHolderInfo}}
** Fixed by: {{PgCommitURL|1aa7cf9eb85972aaf2969306e84f5fc794fbef7f}}
** Fixed by: {{PgCommitURL|2260c7f6d90ecf76d3806d32890a0890688b41e8}}

* Treat oauth_client_secret as a password in UIs
** Owner: Jacob Champion
** Commit: {{PgCommitURL|b3f0be788afc17d2206e1ae1c731d8aeda1f2f59}}
** {{messageLink|20250415191435.55.nmisch%40google.com|dispchar for oauth_client_secret}}

* Doc: mention ALTER TABLE ADD COLUMN no need rewrite when column is virtual generated column
** Owner: Peter Eisentraut
** Commit: {{PgCommitURL|83ea6c54025bea67bcd4949a6d58d3fc11c3e21b}}
** {{messageLink|00e6eb5f5c793b8ef722252c7a519c9a@oss.nttdata.com|DOC: ALTER TABLE ADD COLUMN TABLE REWRITE}}
** Fixed by: {{PgCommitURL|06c4f3ae804}}

* Split OAuth support from libpq into libpq-oauth
** Owner: Daniel Gustafsson
** Commit: {{PgCommitURL|b3f0be788afc17d2206e1ae1c731d8aeda1f2f59}}
** {{messageLink|wbqaa72xxfnqtsspanbteoycmtpb6oshtwbrm7uwiw3pur4ll4@tybxmaasfjkv|Federated Authn/z with OAUTHBEARER}}

* dangling-pointer problem in SQL-language functions
** Owner: Tom Lane
** Commit: {{PgCommitURL|0313c5dc6}}
** {{messageLink|9f975803-1a1c-4f21-b987-f572e110e860%40gmail.com|bug report}}
** Fixed by: {{PgCommitURL|e83a8ae4472}}

* Memory leak in parallel GIN builds
** Owner: Tomas Vondra
** Commit: {{PgCommitURL|8492feb98f6df3f0f03e84ed56f0d1cbb2ac514c}}
** {{messageLink|CAFMdLD4p0VBd8JG%3DNbi%3DBKv6rzFAiGJ_sXSFrw-2tNmNZFO5Kg@mail.gmail.com|bug report}}
** Fixed by: {{PgCommitURL|1681a70df3d6}}

* {{messageLink|20250412123430.8c.nmisch@google.com|Lost symmetry between lower() and regex equivalent, for "I/i in Turkish"}}
** Owner: Jeff Davis
** Commit: {{PgCommitURL|e9931bf}}
** Fixed by: {{PgCommitURL|2e5353b}}

* {{messageLink|20250415213450.1f.nmisch@google.com|Need s/PSQL_CMD_SKIP_LINE/PSQL_CMD_ERROR/ in new pipeline command}}
** Owner: Michael Paquier
** Commit: {{PgCommitURL|41625ab}}
** Fixed by: {{PgCommitURL|5ee7bd9}}

* {{messageLink|20250417135841.33.nmisch@google.com|initcap discrepancy between "pg_unicode_fast" and "unicode"}}
** Owner: Jeff Davis
** Commit: {{PgCommitURL|d3d0983}}
** Fixed by: {{PgCommitURL|90260e2}}

* {{messageLink|20250411203241.e9.nmisch@google.com|TypeCacheOpcCallback does not maintain RelIdToTypeIdCacheHash}}
** Owner: Alexander Korotkov
** Commit: {{PgCommitURL|b85a9d0}}
** Fixed by: {{PgCommitURL|bb78e42}}

* {{messageLink|20250415191435.55.nmisch@google.com|dispchar for oauth_client_secret}}
** Commit: {{PgCommitURL|b3f0be7}}
** Fixed by: {{PgCommitURL|e974f1c}}

== Won't Fix ==

* Rename --with-libcurl to --with-oauth-client
** Owner: Jacob Champion
** Commit: {{PgCommitURL|b3f0be788afc17d2206e1ae1c731d8aeda1f2f59}}
** {{messageLink|CAOYmi+n9DHS_xUatuuspdC8tjtaMzY8P11Y9y5Fz+2pjikkL9g@mail.gmail.com |Federated Authn/z with OAUTHBEARER}}
** This request was withdrawn, with input from Peter E and Robert.

* [https://www.postgresql.org/message-id/aD3EA6jmcDZyPHiv%40nathan add more warnings about MD5 password deprecation]
** Owner: Nathan Bossart

* decide what io_method to default to (Andres Freund)
** Commit: {{PgCommitURL|247ce06b883}}
** {{messageLink|flat/ZR0P278MB04279CB0C1D8F49DE68F168ED2AF2%40ZR0P278MB0427.CHEP278.PROD.OUTLOOK.COM|Doc update}}
** No change was made.
*** {{messageLink|e6db33f3-50de-43d3-9d9f-747c3b376e80%40vondra.me|discussion 1}}
*** {{messageLink|d68e2a4f8c356107e5167408ad80eaa2fac0f57d.camel@j-davis.com|discussion 2}}

* [https://www.postgresql.org/message-id/1514756.1747925490@sss.pgh.pa.us virtual generated columns and planning speed]
** Owner: Peter Eisentraut
** No change was made for v18, and no measurable performance impact has been shown

== Important Dates ==

Current schedule:

* GA: September 25, 2025
* RC 1: September 4, 2025
* Beta 3: August 14, 2025
* Beta 2: July 17, 2025
* Beta 1: May 8, 2025
* Feature Freeze: April 8, 2025 0:00 AoE

== See also ==

* [[Release Management Team]]
* [[PostgreSQL 17 Open Items]]

[[Category:Open_Items]]

FOSDEM/PGDay 2026 Developer Meeting

2025-11-01T15:46:27Z

Petere: Created page with "https://2026.fosdempgday.org/devmeeting/ currently being planned"

https://2026.fosdempgday.org/devmeeting/

currently being planned

Multithreading

2025-10-15T17:46:26Z

Petere: Remove obsolete info about work claimed at 2024.pgconf.dev

== Resources ==

pgsql-hackers thread: https://www.postgresql.org/message-id/31cc6df9-53fe-3cd9-af5b-ac0d801163f4%40iki.fi

PGConf.eu Presentation: https://www.postgresql.eu/events/pgconfeu2023/schedule/session/4845-multi-threaded-postgresql/

Work-in-progress git branch: https://github.com/hlinnaka/postgres/tree/threading

Current related patches: https://commitfest.postgresql.org/current/?tag=34

== Ongoing work ==

These patches are contributing to the effort:

* SendProcSignal() → SendInterrupt(), using latches: https://commitfest.postgresql.org/49/5118/

Done:
* replace strtok(): https://commitfest.postgresql.org/48/5071/
* thread-safety: gmtime_r(), localtime_r() https://commitfest.postgresql.org/48/5084/
* Refactoring postmaster's code to cleanup after child exit: https://www.postgresql.org/message-id/8f2118b9-79e3-4af7-b2c9-bd5818193ca4%40iki.fi
* Remove dependency on setlocale() for collation. https://commitfest.postgresql.org/48/5023/

== TODO ==

=== Global variables ===

Global variables in PostgreSQL fall into a few different categories:

* per-session state
* pointers to shared memory areas
* other variables that are initialized at postmaster startup and never change after that
* constants

Many global variables are used to hold GUCs, and they can fall into any of those categories depending on whether they're PGC_POSTMASTER or PGC_USERSET.

The plan:

* Add annotations to all global variables, to mark which category they fall into. Variables holding per-session state are turned into thread-local variables. The distinction between the other categories is just for documentation purposes.
* Provide a tool that can list all global variables that are missing the annotations (pgguclifetimes). Add that as a compile-time check ideally. This will also be useful for extension authors to find missing annotations in extensions.
** alternative idea: could we use a simple perl script for this, like we do for the PGDLLIMPORT case?
* Potential standalone value:
** "modified once" annotated variables could be put in a separate binary section which would improve performance
** Could help with the engineering overhead of figuring out where to initialize at postmaster startup

=== Extensions ===

Extensions will make the transition at their own pace

* Add field to control file or the PG_MODULE magic to mark whether an extension supports multi-process mode only, or multi-threaded model only, or both
** other considerations: good documentation will be key, also need to work with the extension community to build understanding and consensus

* Python has traditionally been single-threaded, but see https://peps.python.org/pep-0554/
** Python >= 3.12 can spawn non-shared interpreters

* What about Perl, other PLs?
** [https://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support How threaded mod_perl2 works]

* http://postgr.es/m/CA+TgmoYsKJnVjj94HJTSOeS1=TmAgV5L=DVTd_TYL=XUKCbfEA@mail.gmail.com

=== PIDs in user-facing interfaces ===

A few places expose PIDs to users:

* pg_terminate_backend(<pid>)
* pg_stat_activity
* query cancellation

Plan:

* Replace PID with a thread id.
* Could use OS thread ID, but behavior isn't totally consistent across platforms
* Consensus at 2024.pgconf.dev seemed to be that inventing our own 32-bit thread ID would be better
* Possibly pgprocno + counter
* Need to make sure we don't reuse thread IDs too quickly, else we might terminate the wrong backend.
* Potential standalone value: decoupling the relationship between thread and session could enable other features

=== Unix Signals ===

[https://wiki.postgresql.org/wiki/Signals Separate page with more details on this topic.]

We use Unix signals between processes currently. It's hard to use them for inter-thread communication within the same process. When you send a signal, you send it to a process, and any thread in the process can handle it.

* Refactor inter-process signals with something like Procsignal and latches

* With a single-process, you cannot easily "kill <pid>" to send SIGTERM or SIGUSR1 to a single backend anymore. We can provide a "pg_ctl signal" command to replace that.

* Description/Tasks/Components:
** timers (which use sigalarm)
** deadlock detection? (already done with waitlatch so nothing happening in signal handlers so nothing to do here?)
** Sub-sub projects
*** multiplex waiting on a latch and don't rely on signals (latchification project -- replacing setlatch with interrupt driven concept)
*** Abstraction for the C11 thread functions that is portable (think about C11 features and C99 compiler)

=== Replace non-thread safe library functions with thread-safe variants ===

* strerror() -> strerror_r()

* setlocale() -> uselocale()
** no uselocale on windows, workarounds are complex
** https://www.postgresql.org/message-id/CWMW5OZBWJ10.1YFLQWSUE5RE9@neon.tech
** https://www.postgresql.org/message-id/17946-3e84cb577e9551c3@postgresql.org
** http://postgr.es/m/2228884bb1f1a02614b39f71a90c94d2cc8a3a2f.camel@j-davis.com

* getopt_long()
** getopt_long implementation used for windows could be used for other platforms
** rearchitect postmaster startup to change options passing

* Make pg_strtok() re-entrant

* not all string functions with _l have been implemented in glibc

* https://www.postgresql.org/message-id/856e5ec3-879f-42ee-8258-8bcc6ec9bdea@eisentraut.org

=== Misc ===

* Add a GUC to enable multi-threaded mode
* Replace fork() with pthread_create(). Yay!

* Make virtual filedescriptors (fd.c) work with threads
** increase the limit for max number of file descriptors
** diagnose and fix the performance fallout (due to sharing VFD cache and maybe because some OSes don't cope well with large numbers of file descriptors)
** split fd.c into two files: one for virtual file descriptor abstraction and another for "other" file-related functions (see also src/common/file_utils.c)

* Refactoring guc_tables.c
** currently uses memory address of global GUC variable (and that won't work anymore with threads)

* Refactor connection acceptance
** Currently the postmaster accepts connections and then spawns a process
** In the threaded model we'll want 2 processes, a supervisor that only restarts the other process, and the main process with all the threads
** But that means connection acceptance needs to be split out from supervisor tasks

* verify_cb in be-secure-openssl.c uses a (static) global cert_errdetail variable to pass information. Refactor to use x509_store_ctx_get_ex_data

== Open Questions ==

* If an extension launches threads today, it might call SPI or other PostgreSQL functions from a different thread. That works today, if you're careful and only do that from one thread at at time. After replacing global variables with thread-local variables, that no longer works. Or did it work? We have things like longjmp() and stack depth checks that would already break that?

Multithreading

2025-10-15T17:43:33Z

Petere: /* Resources */

== Resources ==

pgsql-hackers thread: https://www.postgresql.org/message-id/31cc6df9-53fe-3cd9-af5b-ac0d801163f4%40iki.fi

PGConf.eu Presentation: https://www.postgresql.eu/events/pgconfeu2023/schedule/session/4845-multi-threaded-postgresql/

Work-in-progress git branch: https://github.com/hlinnaka/postgres/tree/threading

Current related patches: https://commitfest.postgresql.org/current/?tag=34

== Ongoing work ==

These patches are contributing to the effort:

* SendProcSignal() → SendInterrupt(), using latches: https://commitfest.postgresql.org/49/5118/

Done:
* replace strtok(): https://commitfest.postgresql.org/48/5071/
* thread-safety: gmtime_r(), localtime_r() https://commitfest.postgresql.org/48/5084/
* Refactoring postmaster's code to cleanup after child exit: https://www.postgresql.org/message-id/8f2118b9-79e3-4af7-b2c9-bd5818193ca4%40iki.fi
* Remove dependency on setlocale() for collation. https://commitfest.postgresql.org/48/5023/

== TODO ==

=== Global variables ===

Global variables in PostgreSQL fall into a few different categories:

* per-session state
* pointers to shared memory areas
* other variables that are initialized at postmaster startup and never change after that
* constants

Many global variables are used to hold GUCs, and they can fall into any of those categories depending on whether they're PGC_POSTMASTER or PGC_USERSET.

The plan:

* Add annotations to all global variables, to mark which category they fall into. Variables holding per-session state are turned into thread-local variables. The distinction between the other categories is just for documentation purposes.
* Provide a tool that can list all global variables that are missing the annotations (pgguclifetimes). Add that as a compile-time check ideally. This will also be useful for extension authors to find missing annotations in extensions.
** alternative idea: could we use a simple perl script for this, like we do for the PGDLLIMPORT case?
* Potential standalone value:
** "modified once" annotated variables could be put in a separate binary section which would improve performance
** Could help with the engineering overhead of figuring out where to initialize at postmaster startup

=== Extensions ===

Extensions will make the transition at their own pace

* Add field to control file or the PG_MODULE magic to mark whether an extension supports multi-process mode only, or multi-threaded model only, or both
** other considerations: good documentation will be key, also need to work with the extension community to build understanding and consensus

* Python has traditionally been single-threaded, but see https://peps.python.org/pep-0554/
** Python >= 3.12 can spawn non-shared interpreters

* What about Perl, other PLs?
** [https://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support How threaded mod_perl2 works]

* http://postgr.es/m/CA+TgmoYsKJnVjj94HJTSOeS1=TmAgV5L=DVTd_TYL=XUKCbfEA@mail.gmail.com

* Robert volunteered to look into this at 2024.pgconf.dev

=== PIDs in user-facing interfaces ===

A few places expose PIDs to users:

* pg_terminate_backend(<pid>)
* pg_stat_activity
* query cancellation

Plan:

* Replace PID with a thread id.
* Could use OS thread ID, but behavior isn't totally consistent across platforms
* Consensus at 2024.pgconf.dev seemed to be that inventing our own 32-bit thread ID would be better
* Possibly pgprocno + counter
* Need to make sure we don't reuse thread IDs too quickly, else we might terminate the wrong backend.
* Potential standalone value: decoupling the relationship between thread and session could enable other features

* Robert volunteered to look into this at 2024.pgconf.dev

=== Unix Signals ===

[https://wiki.postgresql.org/wiki/Signals Separate page with more details on this topic.]

We use Unix signals between processes currently. It's hard to use them for inter-thread communication within the same process. When you send a signal, you send it to a process, and any thread in the process can handle it.

* Refactor inter-process signals with something like Procsignal and latches

* With a single-process, you cannot easily "kill <pid>" to send SIGTERM or SIGUSR1 to a single backend anymore. We can provide a "pg_ctl signal" command to replace that.

* Description/Tasks/Components:
** timers (which use sigalarm)
** deadlock detection? (already done with waitlatch so nothing happening in signal handlers so nothing to do here?)
** Sub-sub projects
*** multiplex waiting on a latch and don't rely on signals (latchification project -- replacing setlatch with interrupt driven concept)
*** Abstraction for the C11 thread functions that is portable (think about C11 features and C99 compiler)

* Thomas and Heikki volunteered to look into this at 2024.pgconf.dev

=== Replace non-thread safe library functions with thread-safe variants ===

* strerror() -> strerror_r()

* setlocale() -> uselocale()
** no uselocale on windows, workarounds are complex
** https://www.postgresql.org/message-id/CWMW5OZBWJ10.1YFLQWSUE5RE9@neon.tech
** https://www.postgresql.org/message-id/17946-3e84cb577e9551c3@postgresql.org
** http://postgr.es/m/2228884bb1f1a02614b39f71a90c94d2cc8a3a2f.camel@j-davis.com

* getopt_long()
** getopt_long implementation used for windows could be used for other platforms
** rearchitect postmaster startup to change options passing

* Make pg_strtok() re-entrant

* not all string functions with _l have been implemented in glibc

* https://www.postgresql.org/message-id/856e5ec3-879f-42ee-8258-8bcc6ec9bdea@eisentraut.org

* Peter and Nathan volunteered to look into this at 2024.pgconf.dev

=== Misc ===

* Add a GUC to enable multi-threaded mode
* Replace fork() with pthread_create(). Yay!

* Make virtual filedescriptors (fd.c) work with threads
** Heikki volunteered to look into this at 2024.pgconf.dev (with Andres identifying performance fallout)
** increase the limit for max number of file descriptors
** diagnose and fix the performance fallout (due to sharing VFD cache and maybe because some OSes don't cope well with large numbers of file descriptors)
** split fd.c into two files: one for virtual file descriptor abstraction and another for "other" file-related functions (see also src/common/file_utils.c)

* Make bootparse.y and other bison/flex generated code re-entrant
** main parser is already done, but others need work, which is thought to be simple
** Peter volunteered to look into this at 2024.pgconf.dev

* Refactoring guc_tables.c
** currently uses memory address of global GUC variable (and that won't work anymore with threads)

* Refactor connection acceptance
** Currently the postmaster accepts connections and then spawns a process
** In the threaded model we'll want 2 processes, a supervisor that only restarts the other process, and the main process with all the threads
** But that means connection acceptance needs to be split out from supervisor tasks

* verify_cb in be-secure-openssl.c uses a (static) global cert_errdetail variable to pass information. Refactor to use x509_store_ctx_get_ex_data

== Open Questions ==

* If an extension launches threads today, it might call SPI or other PostgreSQL functions from a different thread. That works today, if you're careful and only do that from one thread at at time. After replacing global variables with thread-local variables, that no longer works. Or did it work? We have things like longjmp() and stack depth checks that would already break that?

PostgreSQL 18 Open Items

2025-08-29T08:37:15Z

Petere: fixed: document tsearch upgrade

== Open Issues ==

'''NOTE''': Please place new open items at the end of the list.

'''NOTE''': If known, please list the Owner of the open item.

== Decisions to Recheck Mid-Beta ==

(none)

== Older bugs affecting stable branches ==

=== Live issues ===

* {{messageLink|1=CAH2-Wz%3DPqOziyRSrnN5jAtfXWXY7-BJcHz9S355LH8Dt%3D5qxWQ@mail.gmail.com|2=Incorrect results for (SP-)GIST index-only scans}}
** GIST and SP-GIST indexes hold tuples in memory after releasing the pin on the page, but before returning them to the executor. This allows VACUUM to concurrently clean up any dead tuples from the page's results, and mark the heap pages that held the dead tuples as ALL_VISIBLE, breaking index-only scans.
** Comprehensive fix: {{messageLink|1=CAEze2WgnHJF66BtviDFNCPy26gLrb%2Btfns-Bi62DBfReH0-UCg%40mail.gmail.com|2=Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?}}
** Suggested fix for backpatching, 17-: {{messageLink|1=CAEze2WgH13m=MDST58KLo-NkZpbwBEt4xNWcgtghWBwRj3J0+A%40mail.gmail.com|2=<nowiki>[SP-]GiST IOS visibility bug</nowiki>}}

* {{messageLink|CACJufxGKWZ3WWC7m_F4v-1X7NP2%3D-eU8hjo37P8RfEcdcVzUTg%40mail.gmail.com|2=generation expression node collation inaccurate}}
** generation expression node collation does not match the corresponding data type's collation

* {{messageLink|CACJufxF%3DWDGthXSAQr9thYUsfx_1_t9E6N8tE3B8EqXcVoVfQw%40mail.gmail.com|2=generated column being included in partition key expression}}
** generated column can not be included in partition key expression, some corner case it will be included

* {{messageLink|CACJufxG5wLiATocRTaC%3Dz%2Bkw4mUaasC-50%2Bq9K%3DfOdAr3%3DOGRw%40mail.gmail.com|2=unsafe change individual column when partition key have wholerow reference}}
** we should disallow alter individual column if partition key contains wholerow reference

=== Fixed issues ===

* {{messageLink|873c33c5-ef9e-41f6-80b2-2f5e11869f1c%40garret.ru|Incorrect results for bitmap heap scan.}}
** Certain Bitmap Heap scans only test the visibility map before returning tuples. This can conflict with VACUUM removing tuples, thus causing more tuples to be returned from the scan than what are actually visible.
** Commit: {{PgCommitURL|459e7bf8e2}}

* {{messageLink|CACJufxG59tip2%2B9h%3DrEv-ykOFjt0cbsPVchhi0RTij8bABBA0Q%40mail.gmail.com|bug in stored generated column over domain with constraints.}}
** Commit: {{PgCommitURL|7c872849407}}

* {{messageLink|aBEV3AQwhAMm0v2k%40nathan|2=unsafe access of some catalogs' TOAST tables}}
** We should consider removing pg_replication_origin's TOAST table in v18 to fix a few places that don't set up a snapshot before potentially accessing TOASTed data.
** Commit: {{PgCommitURL|16bf24e0e4}}

* [https://www.postgresql.org/message-id/flat/20250626.155608.568829483879866256.ishii@postgresql.org document StartupMessage correctly for protocol 3.2]
** Commit: {{PgCommitURL|4cff01c4a3}}

* {{messageLink|CACJufxFSC0mcQ82bSk58sO-WJY4P-o4N6RD2M0D%3DDD_u_6EzdQ%40mail.gmail.com|2=create domain can create two not-null constraints}}
** create domain should only create one not-null constraint. This issue exists in PG17 and PG18
** Commit: {{PgCommitURL|647cffd2f3}}

* {{messageLink|CACJufxF-0bqVR%3Dj4jonS6N2Ka6hHUpFyu3_3TWKNhOW_4yFSSg%40mail.gmail.com|2=pg_dump does dump domain notnull constraint comments}}
** pg_dump need dump these domain not null comments. This issue only exist in PG17 and PG18
** Commit: {{PgCommitURL|da71717f0a}}

== Non-bugs ==

* {{messageLink|2045026.1743801143@sss.pgh.pa.us|Fundamental scheduling bug in parallel restore of partitioned tables}}
** Current belief is that this is only a performance hazard, and hence not worth breaking feature freeze to fix. We can take it up in v19 instead.

* {{messageLink|aFzdVCWEhbUgn91k@paquier.xyz|join_search_hook broken by self-join elimination}}
** Yet we only know it affects pg_hint_plan, but enable_self_join_elimination GUC provides a workaround.
** Commit: {{PgCommitURL|fc069a3a6319}}

== Resolved Issues ==

=== resolved before 18rc1 ===

* {{messageLink|flat/CAKAnmmKwiMHik5AHmBEdf5vqzbOBbcwEPHo4-PioWeAbzwcTOQ@mail.gmail.com|Enable data checksums by default}}
** Commit: {{PgCommitURL|04bec894a0}}
** Data checksums have been enabled by default. pg_upgrade cannot upgrade between non-checksum and checksum instances, so some additional steps are required by the user. Check whether the upgrade experience is tolerable and sufficiently documented. See the following list of threads that might be enhancing the end user experience:
*** {{messageLink|flat/E07A611B-9CF3-4FDB-8CE8-A221E39040EC%40yesql.se|Changing the state of data checksums in a running cluster}}
** Also, a thread complaining about the extremely visible performance regression that results:
*** {{messageLink|flat/CADE6Lvh62KopfpyScY-sMvLQE6Y5BBfAnt2wV-nsvZLetF+j6g@mail.gmail.com|Possible regression in PG18 beta1}}
** {{messageLink|flat/941f0190-e3c6-4622-9ac7-c04e936e5fdb@vondra.me|strange perf regression with data checksums}}
** Owner: Peter Eisentraut?
** result: No clear proposals to change the default. We're likely keeping checksums enabled.

* [https://www.postgresql.org/message-id/flat/20250617.101056.1437027795118961504.ishii@postgresql.org handle servers that don't send BackendKeyData gracefully]
** Owner: Heikki Linnakangas
** Fixed by: {{PgCommitURL|f6f0542266f}}, {{PgCommitURL|e411a8d25a}}, {{PgCommitURL|807ee417e5}}

* {{messageLink|20250809222338.cc.nmisch@google.com|"cannot take query snapshot during logical decoding" incompatible w/ pglogical row_filter}}
** Owner: Heikki Linnakangas
** Commit: {{PgCommitURL|1585ff7387}}
** Fixed by: {{PgCommitURL|50f770c3d9}}

* {{messageLink|20250820104226.8ba51e43164cd590b863ce41%40sraoss.co.jp|Don't treat virtual generated columns as missing statistics in vacuumdb --missing-stats-only}}
** Owner: Nathan Bossart
** Fixed by: {{PgCommitURL|b63952a781}}

* {{messageLink|CAHGQGwHh43suEfss1wvBsk7vqiou%3DUY0zcy8HGyE5hBp%2BHZ7SQ%40mail.gmail.com|vacuumdb --missing-stats-only and permission issue}}
** Owner: Nathan Bossart
** Fixed by: {{PgCommitURL|984d7165dd}}

* {{messageLink|CA%2BhUKGJfOGBf55oLsgvv1PZSuJm1%2BR8yFbVHsP3VnEu%3DdOqayQ%40mail.gmail.com|2=VM corruption on standby}}
** Owner: Alexander Korotkov
** likely caused by "Get rid of WALBufMappingLock" {{PgCommitURL|bc22dc0e0ddc2dcb6043a732415019cc6b6bf683}}
** Fixed by: {{PgCommitURL|c13070a27b}}

* {{messageLink|20241125012400.6f.nmisch@google.com|"object locking for GRANT/REVOKE" removed a comment about a failure mode it didn't change, and it reduced test coverage}}
** Owner: Peter Eisentraut
** Commit: {{PgCommitURL|d31bbfb}}
** Fixed by: {{PgCommitURL|e36fa9319b}}, {{PgCommitURL|310d04169a}}

* {{messageLink|1fd1a421-4609-4d46-a1af-ab74d5de504a%40tantorlabs.ru|Remove self joins causes 'variable not found in subplan target lists' error}}
** Owner: Tom Lane
** Dates to {{PgCommitURL|a3179ab692be4314d5ee5cd56598976c487d5ef2}}, so it's not actually related to remove-self-joins patch
** Fixed by: {{PgCommitURL|3aee6283709}}, {{PgCommitURL|b8a1bdc458e}}

* {{messageLink|flat/653f3b84-fc87-45a7-9a0c-bfb4fcab3e7d%40eisentraut.org|fixing tsearch locale support}}
** Commit: {{PgCommitURL|fb1a18810f0}}
** Text search locale support has been updated and integrated into the common locale framework. Possible upgrade issues should probably at least be noted in the release notes.
** Owner: Peter Eisentraut?
** Fixed by: {{PgCommitURL|d1073c3b4cc}}

=== resolved before 18beta3 ===

* [https://www.postgresql.org/message-id/flat/08129593-6f3c-4fb9-94b7-5aa2eefb99b0%40oss.nttdata.com pg_dumpall dumps global objects with --statistics-only or --no-schema]
** Owner: Jeff Davis
** Fixed by: {{PgCommitURL|973caf7291}}

* [https://www.postgresql.org/message-id/flat/7cc52488-f876-4ad3-affd-6e4b0ef0cb09%40eisentraut.org decide on new pg_dump flags and whether stats should be enabled by default]
** Owner: Jeff Davis
** Fixed by: {{PgCommitURL|a3e8dc1438}}

* [https://www.postgresql.org/message-id/eb224uegsga2hgq7dfq3ps5cduhpqej7ir2hjxzzozjthrekx5%40dysei6buqthe Custom pgstat support performance regression for simple queries]
** Owner: Michael Paquier
** Commit: {{PgCommitURL|fc415edf8ca8}}
** Fixed by: {{PgCommitURL|ac000fca743e}} and {{PgCommitURL|793928c2d5ac}}

* {{messageLink|87qzyghw2x.fsf@wibble.ilmari.org|tab completion for ALTER DATABASE/ROLE/USER ... RESET}}
** Owner: Tomas Vondra
** Commit: {{PgCommitURL|9df8727c5067}} {{PgCommitURL|c407d5426b87}}
** Fixed by: {{PgCommitURL|dbf5a83d4650}} and {{PgCommitURL|ca09ef3a6aa6}}

* {{messageLink|20250708212819.09.nmisch@google.com|non-text mode for pg_dumpall: DROP, options ignored, lexing, if-not-exists, etc.}}
** Owner: Andrew Dunstan
** Commit: {{PgCommitURL|1495eff}}
** Fixed by: {{PgCommitURL|4a9ee867bff}} and {{PgCommitURL|3a954813a0f}}

* {{messageLink|CAOYmi%2BnGstyp4OyL8SFCm3dtkBzNJqGwL7xYhe85%3Dj2hhaXAMw%40mail.gmail.com|Unnecessary CPU usage with OAuth on Mac and BSD}}
** [https://www.postgresql.org/message-id/CAOYmi%2BnDZxJHaWj9_jRSyf8uMToCADAmOfJEggsKW-kY7aUwHA%40mail.gmail.com OAuth: fix performance bug with stuck multiplexer events]
** Owner: Jacob Champion
** Fixed-by: {{PgCommitURL|ff5b082}}, {{PgCommitURL|3d9c034}}, {{PgCommitURL|1749a12}}, {{PgCommitURL|3e31166}}, {{PgCommitURL|1443b6c}}, {{PgCommitURL|ebaaf38}}

* [https://www.postgresql.org/message-id/19006-80fcaaf69000377e@postgresql.org Assert(BufferIsPinned) in BufferGetBlockNumber() is triggered for forwarded buffer]
** Commit: {{PgCommitURL|b421223172a2}}

* Revisit libpq-oauth naming/ABI
** Commit: {{PgCommitURL|b0635bfda}}
** The libpq-oauth module relies on libpq internals, so it'll be renamed every major release to avoid ABI incompatibilities. This reduces developer load at the expense of {{messageLink|CAOYmi%2B%3Dcs%2BgDTAH0L%2B3JzpRLeHPOXDQxu7MOfsbjah9SkAP_kw%40mail.gmail.com|packager pain}}. Is that acceptable?
** Owner: Jacob Champion
** Resolution: {{messageLink|CAOYmi%2Bm5L%3D-S8QuZgLcSdHyXreVDCVr2NBbCZVcdVzE8B2y5Xg%40mail.gmail.com|No objections raised.}}

=== resolved before 18beta2 ===

* queryId constant squashing does not support prepared statements
** Owner: Alvaro Herrera
** Commit: {{PgCommitURL|62d712ecfd94}}
** {{messageLink|CAA5RZ0tRXoPG2y6bMgBCWNDt0Tn%3DunRerbzYM%3DoW0syi1%3DC1OA%40mail.gmail.com|bug report}}
** Fixed by: {{PgCommitURL|c2da1a5d6325a92d834c9cb036f65d362e4bfc3e}}

* [https://www.postgresql.org/message-id/26983.1748418675@localhost Foreign key validation failure in 18beta1]
** Owner: Alvaro Herrera
** Commit: {{PgCommitURL|b663b9436e7509b5e73c8c372539f067cd6e66c1}}
** Fixed by: {{PgCommitURL|cc733ed164c5b57fdf34d16e4cc8e9bbdc171699}}

* [https://postgr.es/m/3eb40b3e-45c7-426a-b7f8-81f7d05a9b53@oss.nttdata.com pg_get_process_memory_contexts can cause the target session to error out]
** Defect in commit 042a66291b04f473cbc72f95f07438abd75ae3a9
** Owner: Daniel Gustafsson
** {{messageLink|65EB9E45-BD41-4DA7-A689-7A358CF7826F@yesql.se|Patch}}
** Commit: {{PgCommitURL|fb844b9f06568a}}

* [https://postgr.es/m/605328.1747710381@sss.pgh.pa.us issues with generic plans and "initial" pruning]
** Commit: {{PgCommitURL|525392d57}}
** Owner: Amit Langote
** Fixed by: {{PgCommitURL|1722d5eb05d8e5d2e064cd1798abcae4f296ca9d}}

* Refactoring for ChangeVarNodesExtended()
** Owner: Alexander Korotkov
** Commit: {{PgCommitURL|fc069a3a6319b5bf40d2f0f1efceae1c9b7a68a8}}
** {{messageLink|CAMbWs49PE3CvnV8vrQ0Dr%3DHqgZZmX0tdNbzVNJxqc8yg-8kDQQ%40mail.gmail.com|Some problems regarding the self-join elimination code}}
** Fixed by: {{PgCommitURL|ab42d643c14509cf1345588f55d798284b11a91e}}

* Clean up injection point tests in AIO code
** Owner: Andres Freund (note from Michael Paquier: I'm OK to handle this one).
** Commit: {{PgCommitURL|93bc3d75d8e1}}
** {{messageLink|Z_y9TtnXubvYAApS@paquier.xyz|Support for runtime parameters in injection points, for AIO tests}}
** Fixed by: {{PgCommitURL|371f2db8b05e}}, {{PgCommitURL|36e5fda63260}}, {{PgCommitURL|c259ba881c10}}

* [https://postgr.es/m/18923-e79273f87c6bed69%40postgresql.org pg_dump 18beta1 fails to process complex table names]
** Commit: {{PgCommitURL|9c02e3a986}}
** Owner: Nathan Bossart
** Fixed by: {{PgCommitURL|a6060f1cbe}}

* Regression in statement locations with nested statements
** Commit: {{PgCommitURL|499edb09741b}}
** Owner: Michael Paquier
** [https://postgr.es/m/844a3b38-bbf1-4fb2-9fd6-f58c35c09917@pgbackrest.org bug report]
** Fixed by: {{PgCommitURL|06450c7b8c70}}

* [https://postgr.es/m/CAAeiqZ0o2p4SX5_xPcuAbbsmXjg6MJLNuPYSLUjC%3DWh-VeW64A%40mail.gmail.com incorrect reltuples after upgrade from <v14]
** Commit: {{PgCommitURL|1fd1bd8710}}
** Owner: Nathan Bossart
** Fixed by: {{PgCommitURL|5d6eac80cd}}

* [https://www.postgresql.org/message-id/CAD21AoConf6tkVCv-=JhQJj56kYsDwo4jG5+WqgT+ukSkYomSQ@mail.gmail.com assert failure during eager scanning]
** Commit: {{PgCommitURL|052026c9b903}}
** Owner: Melanie Plageman
** Fixed by: {{PgCommitURL|4c08ecd1618}}

* Prevent stack overflow in OAuth parsers
** Owner: Jacob Champion
** Commit: {{PgCommitURL|b3f0be788a}}
** {{messageLink|CAOYmi%2Bm71aRUEi0oQE9ciBnBS8xVtMn3CifaPu2kmJzUfhOZgA%40mail.gmail.com|Patch/discussion}}
** Fixed by: {{PgCommitURL|cbc8fd0c9}}

* [https://www.postgresql.org/message-id/aCvzJNwetyEI3Sgo%40paquier.xyz Redefine plan ID as int64 rather than uint64]
** The same problem applies to the query ID, but it is an older problem. The plan ID is new in v18.
** Commit: {{PgCommitURL|2a0cd38da5cc}}
** Owner: Michael Paquier
** Fixed by: {{PgCommitURL|e050af28686e}}

* Enable statistics in pg_dump by default (Jeff Davis)?
** {{messageLink|1=CAKAnmmKCgnqcd3x4Z+5yXsY7urpDS6D_NZG7pr=DYD=LHt5X4g@mail.gmail.com|2=Greg Sabino Mullane}}
** {{messageLink|1=CA+TgmoYGuEC=E4TbomRyqO8+Uav=90G0dYXw=rA1d5UmRB76Yg@mail.gmail.com|2=Robert Haas}}
** decision was opt-in for pg_dump[all] and opt-out for pg_upgrade/pg_restore
** Fixed by: {{PgCommitURL|34eb2a80d5}}

* [https://www.postgresql.org/message-id/flat/18944-8a926c30f68387dd%40postgresql.org Assertion Failure in psql with idle_session_timeout set]
** Owner: Michael Paquier
** Commit: {{PgCommitURL|41625ab8ea3d}}
** Fixed by: {{PgCommitURL|7f3381c7ee66}}

* [https://www.postgresql.org/message-id/18920-b350b1c0a30af006@postgresql.org LOAD '$libdir/plugins' no longer works in 18beta1]
** Owner: Peter Eisentraut
** Commit: {{PgCommitURL|4f7f7b037585}}
** Fixed by: {{PgCommitURL|f777d77387}}

* {{messageLink|20250415155850.9b.nmisch@google.com|Trademark risk in new test}}
** Owner: Tom Lane
** Commit: {{PgCommitURL|01463e1}}
** Fixed by: {{PgCommitURL|4b05ebf095}}

* [https://postgr.es/m/18947-cdd2668beffe02bf@postgresql.org failed Assert("len_to_wrt >= 0") in pg_stat_statements]
** Owner: Michael Paquier
** Commit: {{PgCommitURL|499edb09741b}}
** Fixed by: {{PgCommitURL|f85f6ab051b7}}

* [https://postgr.es/m/CAE7r3MJ611B9TE=YqBBncewp7-k64VWs+sjk7XF6fJUX77uFBA@mail.gmail.com Improvements in GIN amcheck]
** Commit: {{PgCommitURL|14ffaece0fb53fed8ddbc46d2b353e1c4834863a}}
** Owner: Tomas Vondra
** Fixed by: {{PgCommitURL|0cf205e122ae0fe9333ccf843c2269f13ddc32fc}}

* {{messageLink|20250706161319.c1.nmisch@google.com|Remove PQservice()}}
** Owner: Michael Paquier
** Commit: {{PgCommitURL|4b99fed75}}
** Fixed by: {{PgCommitURL|fef6da9}}

* [https://www.postgresql.org/message-id/CAK_s-G2Q7de8Q0qOYUR=_CTB5FzzVBm5iZjOp+meVWpMpmfO0w@mail.gmail.com virtual generated columns are unsafe if superuser selects]
** Owner: Peter Eisentraut
** Fixed by: {{PgCommitURL|0cd69b3d7ef}}

* {{messageLink|1500090.1745443021%40sss.pgh.pa.us|Non-reproducible AIO failure}}
** Owner: Andres Freund
** Partially fixed by: {{PgCommitURL|e9a3615a522}}, remaining issue is not reproducible

=== resolved before 18beta1 ===

* Fix guidance for running vacuumdb after pg_upgrade
** Owner: Nathan Bossart
** Commit: {{PgCommitURL|c9d502eb68}}
** {{messageLink|aAfxfKC82B9NvJDj%40msg.df7cb.de|pgsql: Update guidance for running vacuumdb after pg_upgrade.}}
** Fixed by: {{PgCommitURL|d5f1b6a75b}}, {{PgCommitURL|9879105024}}

* Not null not valid: pg_dump output is inconsistent on table inheritence tables
** Owner: Álvaro Herrera
** Commit: {{PgCommitURL|a379061a22a8fdf421e1a457cc6af8503def6252}}
** {{messageLink|CACJufxGHNNMc0E2JphUqJMzD3%3DbwRSuAEVBF5ekgkG8uY0Q3hg%40mail.gmail.com| pg_dump not null not valid is wrong}}
** Fixed by: {{PgCommitURL|0e13b13d26e}}

* Difference in statistics on original and restored database
** Owner: Ashutosh Bapat
** Commit: {{PgCommitURL|172259afb5}}
** {{messageLink|1=CAExHW5sFOgcUkVtZ8=QCAE+jv=sbNdBKq0xZCNJTh7019ZM+CQ@mail.gmail.com|2=Original report}}
** {{messageLink|1=CAExHW5uX1oH3f9WNGJf0E-0C9JFO20EryT0nMN42gfia5rkQLA@mail.gmail.com|2=Fix discussion}}
** Once this issue is fixed, we need to enable dumping statistics and comparing them in pg_upgrade/002_pg_upgrade.pl. The patch for the same is posted in the thread.

* Use-after-free with stats_fetch_consistency = snapshot and pg_stat_get_backend_wal()
** Owner: Michael Paquier
** Commit: {{PgCommitURL|76def4cdd}}
** {{messageLink|f1788cc0-253a-4a3a-aee0-1b8ab9538736@gmail.com|Details of report}}
** Fixed by: {{PgCommitURL|3191a593d6de}}

* Performance regression in SQL-language functions
** Owner: Tom Lane
** Commit: {{PgCommitURL|0dca5d68d}}
** {{messageLink|1112592.1744572204@sss.pgh.pa.us|Performance issues with v18 SQL-language-function changes}}
** Fixed by: {{PgCommitURL|0400ae4a6}} and four preceding patches

* Memory mismanagement leads to infinite loop in walsender
** Owner: Tom Lane
** Commit: {{PgCommitURL|1afe31f03}}
** {{messageLink|CAO6_XqoJA7-_G6t7Uqe5nWF3nj+QBGn4F6Ptp%3DrUGDr0zo+KvA%40mail.gmail.com|bug report}}
** Fixed by: {{PgCommitURL|80b727eb9}}

* Not-null-in-pg_constraint changes cause parallel restore to deadlock
** Owner: Alvaro Herrera
** Commit: {{PgCommitURL|14e87ffa5c543b5f30ead7413084c25f7735039f}}
** {{messageLink|1280408.1744650810@sss.pgh.pa.us|Re: not null constraints, again}}
** Fixed by: {{PgCommitURL|11ff192b5}}

* Avoid core dump in pgstat_read_statsfile()
** Owner: Michael Paquier
** Commit: {{PgCommitURL|7949d9594582}}
** {{messageLink|aAieZAvM+K1d89R2@ip-10-97-1-34.eu-west-3.compute.internal|Avoid core dump in pgstat_read_statsfile()}}
** Fixed by: {{PgCommitURL|923ae50cf559}}

* Assertion failure in discardAbortedPipelineResults() with psql's pipeline mode
** Owner: Michael Paquier
** Commit :{{PgCommitURL|2cce0fe440fb}}
** {{messageLink|ebf6ce77-b180-4d6b-8eab-71f641499ddf@postgrespro.ru|bug report}}
** Fixed by: {{PgCommitURL|3631612eae9c}}

* Use extended stats for precise estimation of bucket size in hash join
** Owner: Alexander Korotkov
** Commit: {{PgCommitURL|6bb6a62f3cc45624c601d5270673a17447734629}}
** {{messageLink|18885-da51324078588253@postgresql.org|ERROR: corrupt MVNDistinct entry - 2}}
** Fixed by: {{PgCommitURL|9f404d7922e8831dc49bfa225530ba5309900e4e}}

* Bugs in self-join elimination
** Owner: Alexander Korotkov
** Commit: {{PgCommitURL|fc069a3a6319b5bf40d2f0f1efceae1c9b7a68a8}}
** {{messageLink|CAMbWs49PE3CvnV8vrQ0Dr%3DHqgZZmX0tdNbzVNJxqc8yg-8kDQQ%40mail.gmail.com|Some problems regarding the self-join elimination code}}
** {{messageLink|CAPpHfdtTxSs%2Bt8PXjJ_EC5roaQRLPyxt71M%3DAJvrGjYFC-wK5g%40mail.gmail.com|ERROR: too late to create a new PlaceHolderInfo}}
** Fixed by: {{PgCommitURL|1aa7cf9eb85972aaf2969306e84f5fc794fbef7f}}
** Fixed by: {{PgCommitURL|2260c7f6d90ecf76d3806d32890a0890688b41e8}}

* Treat oauth_client_secret as a password in UIs
** Owner: Jacob Champion
** Commit: {{PgCommitURL|b3f0be788afc17d2206e1ae1c731d8aeda1f2f59}}
** {{messageLink|20250415191435.55.nmisch%40google.com|dispchar for oauth_client_secret}}

* Doc: mention ALTER TABLE ADD COLUMN no need rewrite when column is virtual generated column
** Owner: Peter Eisentraut
** Commit: {{PgCommitURL|83ea6c54025bea67bcd4949a6d58d3fc11c3e21b}}
** {{messageLink|00e6eb5f5c793b8ef722252c7a519c9a@oss.nttdata.com|DOC: ALTER TABLE ADD COLUMN TABLE REWRITE}}
** Fixed by: {{PgCommitURL|06c4f3ae804}}

* Split OAuth support from libpq into libpq-oauth
** Owner: Daniel Gustafsson
** Commit: {{PgCommitURL|b3f0be788afc17d2206e1ae1c731d8aeda1f2f59}}
** {{messageLink|wbqaa72xxfnqtsspanbteoycmtpb6oshtwbrm7uwiw3pur4ll4@tybxmaasfjkv|Federated Authn/z with OAUTHBEARER}}

* dangling-pointer problem in SQL-language functions
** Owner: Tom Lane
** Commit: {{PgCommitURL|0313c5dc6}}
** {{messageLink|9f975803-1a1c-4f21-b987-f572e110e860%40gmail.com|bug report}}
** Fixed by: {{PgCommitURL|e83a8ae4472}}

* Memory leak in parallel GIN builds
** Owner: Tomas Vondra
** Commit: {{PgCommitURL|8492feb98f6df3f0f03e84ed56f0d1cbb2ac514c}}
** {{messageLink|CAFMdLD4p0VBd8JG%3DNbi%3DBKv6rzFAiGJ_sXSFrw-2tNmNZFO5Kg@mail.gmail.com|bug report}}
** Fixed by: {{PgCommitURL|1681a70df3d6}}

* {{messageLink|20250412123430.8c.nmisch@google.com|Lost symmetry between lower() and regex equivalent, for "I/i in Turkish"}}
** Owner: Jeff Davis
** Commit: {{PgCommitURL|e9931bf}}
** Fixed by: {{PgCommitURL|2e5353b}}

* {{messageLink|20250415213450.1f.nmisch@google.com|Need s/PSQL_CMD_SKIP_LINE/PSQL_CMD_ERROR/ in new pipeline command}}
** Owner: Michael Paquier
** Commit: {{PgCommitURL|41625ab}}
** Fixed by: {{PgCommitURL|5ee7bd9}}

* {{messageLink|20250417135841.33.nmisch@google.com|initcap discrepancy between "pg_unicode_fast" and "unicode"}}
** Owner: Jeff Davis
** Commit: {{PgCommitURL|d3d0983}}
** Fixed by: {{PgCommitURL|90260e2}}

* {{messageLink|20250411203241.e9.nmisch@google.com|TypeCacheOpcCallback does not maintain RelIdToTypeIdCacheHash}}
** Owner: Alexander Korotkov
** Commit: {{PgCommitURL|b85a9d0}}
** Fixed by: {{PgCommitURL|bb78e42}}

* {{messageLink|20250415191435.55.nmisch@google.com|dispchar for oauth_client_secret}}
** Commit: {{PgCommitURL|b3f0be7}}
** Fixed by: {{PgCommitURL|e974f1c}}

== Won't Fix ==

* Rename --with-libcurl to --with-oauth-client
** Owner: Jacob Champion
** Commit: {{PgCommitURL|b3f0be788afc17d2206e1ae1c731d8aeda1f2f59}}
** {{messageLink|CAOYmi+n9DHS_xUatuuspdC8tjtaMzY8P11Y9y5Fz+2pjikkL9g@mail.gmail.com |Federated Authn/z with OAUTHBEARER}}
** This request was withdrawn, with input from Peter E and Robert.

* [https://www.postgresql.org/message-id/aD3EA6jmcDZyPHiv%40nathan add more warnings about MD5 password deprecation]
** Owner: Nathan Bossart

* decide what io_method to default to (Andres Freund)
** Commit: {{PgCommitURL|247ce06b883}}
** {{messageLink|flat/ZR0P278MB04279CB0C1D8F49DE68F168ED2AF2%40ZR0P278MB0427.CHEP278.PROD.OUTLOOK.COM|Doc update}}
** No change was made.

* [https://www.postgresql.org/message-id/1514756.1747925490@sss.pgh.pa.us virtual generated columns and planning speed]
** Owner: Peter Eisentraut
** No change was made for v18, and no measurable performance impact has been shown

== Important Dates ==

Current schedule:

* GA: September 25, 2025
* RC 1: September 4, 2025
* Beta 3: August 14, 2025
* Beta 2: July 17, 2025
* Beta 1: May 8, 2025
* Feature Freeze: April 8, 2025 0:00 AoE

== See also ==

* [[Release Management Team]]
* [[PostgreSQL 17 Open Items]]

[[Category:Open_Items]]