On Sun, May 18, 2025 at 3:48 AM Shaik Mohammad Mujeeb <
mujeeb...@zohocorp.com> wrote:
> Hi Michael Paquier,
>
> > I don't quite see the value in the comment addition you are suggesting
> > here: all the user-facing features related to query IDs use signed 64b
> > integers, and are documented as s
Hi Michael Paquier,
> I don't quite see the value in the comment addition you are suggesting
> here: all the user-facing features related to query IDs use signed 64b
> integers, and are documented as such in the official docs. The fact
> that we store an unsigned value in the backend core cod
On Fri, May 16, 2025 at 04:05:01PM +0530, Shaik Mohammad Mujeeb wrote:
> This conversion is intentional - most likely to match the bigint
> type of the queryid column in pg_stat_statements. However, without
> an explicit comment, this can be misleading. A beginner reading this
> might misinterpret
Hi Shaik
> While it's true that no arithmetic or logical operations are performed on
queryid after the assignment, the overflow technically > occurs at the
point of assignment itself. For example, *entry->key.queryid* holds the
value *12747288675711951805* as a
> *uint64*, but after assigning it to
Hi Ilia Evdokimov,
While it's true that no arithmetic or logical operations are performed on
queryid after the assignment, the overflow technically occurs at the point of
assignment itself. For example, entry->key.queryid holds the value
12747288675711951805 as a uint64, but after assigning it
On 15.05.2025 10:08, Shaik Mohammad Mujeeb wrote:
Hi Developers,
In pg_stat_statements.c, the function /pg_stat_statements_internal()/
declares the /queryid/ variable as *int64*, but assigns it a value of
type *uint64*. At first glance, this might appear to be an overflow
issue. However, I t
