| From: | Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, sirisha chamarthi <sirichamarthi22(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <akorotkov(at)postgresql(dot)org> |
| Subject: | Re: WAIT FOR command should do some query jumbling |
| Date: | 2026-08-31 15:08:54 |
| Message-ID: | CAN12+YLGPMGerhXfXOUnXDumUu1csSYiw6z8iLvH8pUSc2h8pw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I'm still digging into the details here, but what are folks' thoughts on
> how critical this patch is for v19? IOW is it a big deal if we leave it
> out of v19 and put it in v20? Or should the pg_stat_statements spam be a
> blocker for its release?
I am not sure if I would call it a blocker. The pg_stat_statements spam will
be confined to a standby, unless the MODE used is primary_flush, which
ISTM will be the lesser used case. But for both cases, the workaround is
to disable utility statement tracking. So, there is a workaround.
This is very much similar to how lack of SAVEPOINT normalization with
many unique savepoint names would cause pg_stat_statements before we
fixed that.
But if we go with v1-, this seems like a simple enough fix to get it, if
there
is still a chance to do so.
--
Sami
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nitin Jadhav | 2026-08-31 15:19:42 | Re: aio: Async fsyncs for crash recovery and checkpointer |
| Previous Message | Peter Eisentraut | 2026-08-31 14:47:16 | WAIT FOR NO_THROW option could use some documentation |