Re: WAIT FOR command should do some query jumbling

Hello,

Thanks for the patch. I tested it on with a
clean meson build (cassert enabled). It applies cleanly to master
(92819e57945) and does what it says:

WAIT FOR LSN '0/0' WITH (MODE 'primary_flush');
WAIT FOR LSN '0/1' WITH (MODE 'primary_flush');
WAIT FOR LSN '0/2' WITH (MODE 'primary_flush');

SELECT calls, query FROM pg_stat_statements WHERE query LIKE 'WAIT FOR%';
calls | query
-------+---------------------------------------------
3 | WAIT FOR LSN $1 WITH (MODE 'primary_flush')

Same result with real LSNs from pg_current_wal_lsn(), and the queryid is
stable across resets. Jumbling of other statements is unaffected.

Full test suite passes: 362 OK, 0 failures (the 40 skips are all
PG_TEST_EXTRA opt-ins). No new compiler warnings from the patched files.

One question: the LSN is normalized, but option values still aren't.
Varying TIMEOUT produces separate entries:

calls | query
-------+-----------------------------------------------------------
1 | WAIT FOR LSN $1 WITH (MODE 'primary_flush', TIMEOUT 1000)
1 | WAIT FOR LSN $1 WITH (MODE 'primary_flush', TIMEOUT 2000)
1 | WAIT FOR LSN $1 WITH (MODE 'primary_flush', TIMEOUT 3000)

A client computing a dynamic timeout (remaining budget, backoff) would
still spam pg_stat_statements, which seems close to the original
complaint. I realize DefElem isn't jumble-annotated and this is
consistent with other utility statements, so it may be out of scope
here, but wanted to raise it in case TIMEOUT is expected to vary in
practice while MODE isn't.

Regards,
Rithvika Devisetti

On Fri, Aug 28, 2026 at 4:07 PM sirisha chamarthi <sirichamarthi22(at)gmail(dot)com>
wrote:

> Hi Peter,
>
> On Fri, Aug 28, 2026 at 2:48 PM Peter Eisentraut <peter(at)eisentraut(dot)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, 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.
>>
>
> +1 to your suggestion. Please find the attached patch to address this
> issue.
>
> Regards,
> Sirisha
>
>