Re: WAIT FOR command should do some query jumbling

From: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, 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-09-25 16:48:59
Message-ID: CAN12+YJxW=g8x_6o7Fnhx9ALo2BnhN7+6M1NmsnA-7_qum2Bkw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Alexander,

> Two things today: waits differing only in the timeout get an entry
> each,

I agree this is not ideal, and it's the point I raised earlier.

> and so does the same wait with its options written in another
> order.

I am not sure we should add the additional complexity in the custom
jumble to deal with this. I don't anticipate this will be a problem in
the real world. Scripts and drivers will use the same order. Also we
don't really guarantee that in other commands:

```
VACUUM (ANALYZE, VERBOSE) and VACUUM (VERBOSE, ANALYZE)
```

give different queryIds, and the same is true of COPY and every other
command taking an option list.

If we want option order to not affect the queryId, I think we should
teach jumbling to do this for all commands that take options; the
consumers of utility_option_list and copy_generic_opt_list, and
probably some other places.

So my preference is to deal with the TIMEOUT jumbling only, and
keep the ordering aspect out of this for now.

Maybe others have a different opinion.

--
Sami Imseih
Amazon Web Services (AWS)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Burd 2026-09-25 17:09:01 Re: Add counted_by attribute
Previous Message Kirill Reshke 2026-09-25 16:46:46 Re: ON CONFLICT DO SELECT returns rows hidden by a view