WAIT FOR command should do some query jumbling
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253598psql -h localhost -U postgresBuilt from patchset v3 (message #3), August 30, 2026 at 01:18 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253598_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253598_3 && git checkout t253598_3Patchset v3 (message #3) is on t253598_3
Right now, WAIT FOR commands are recorded literally in
pg_stat_statements. I think the actual LSN value should be replaced by
some placeholder, like
WAIT FOR LSN $1
Otherwise, a client library or framework that runs this command
repeatedly would needlessly spam pg_stat_statements.
The query jumbling facilities should be used to handle this.
Hi Peter,
On Fri, Aug 28, 2026 at 2:48 PM Peter Eisentraut <peter@eisentraut.org>
wrote:
Right now, WAIT FOR commands are recorded literally in
pg_stat_statements. I think the actual LSN value should be replaced by
some placeholder, likeWAIT FOR LSN $1
Otherwise, a client library or framework that runs this command
repeatedly would needlessly spam pg_stat_statements.The query jumbling facilities should be used to handle this.
+1 to your suggestion. Please find the attached patch to address this issue.
Regards,
Sirisha
Hi,
The query jumbling facilities should be used to handle this.
+1 for this. I think we need to do a bit more than what is suggested
in v1-0001, which only normalizes the target LSN. I think we should
also look at the rest of the rest of the WAIT FOR syntax and normalize
option values, for example
```
WAIT FOR LSN 'FFFFFFFF/FFFFFFFF'
WITH (MODE 'primary_flush', TIMEOUT '1ms', NO_THROW);
WAIT FOR LSN 'FFFFFFFE/FFFFFFFF'
WITH (MODE 'primary_flush', TIMEOUT '2ms', NO_THROW);
```
These should normalize to one pg_stat_statements entry
```
WAIT FOR LSN $1 WITH (MODE $2, TIMEOUT $3, NO_THROW)
```
Because these options are carried as DefElem, I think we should also
track DefElem arg_location, and then statement parse nodes with such
DefElem option lists can use pg_node_attr(custom_query_jumble) to
traverse those lists and normalize the option values.
WAIT FOR is one case, but I think the same approach could also be
useful for other utility statements such as VACUUM and ALTER ROLE. For
example, ALTER ROLE could normalize PASSWORD and VALID UNTIL. I have
kept this series focused on WAIT FOR for now, though.
So, attached in v2, v2-0001 adds the DefElem arg_location tracking,
and v2-0002 adds the WAIT FOR jumbling changes.
JumbleDefElemOptions() is a small helper in queryjumblefuncs.c that
other statements can use to implement the same kind of option
jumbling.
CC'ing Michael also to get his thoughts on the approach.
--
Sami Imseih
Amazon Web Services (AWS)