On Thu, May 22, 2025 at 02:36:38PM +1200, David Rowley wrote:
> You could argue that if it reduces the locations that need to be
> changed by using a typedef, then it's a win. But there are also
> negative aspects to typedefs that need to be considered. For me, those
> are the added level of indire
On Thu, 22 May 2025 at 02:58, Peter Eisentraut wrote:
>
> On 20.05.25 08:38, Michael Paquier wrote:
> > On Tue, May 20, 2025 at 05:51:51PM +1200, David Rowley wrote:
> >> Given the planId stuff is new and has the same issue, I think that
> >> pushes me towards thinking now is better than later for
On 20.05.25 08:38, Michael Paquier wrote:
On Tue, May 20, 2025 at 05:51:51PM +1200, David Rowley wrote:
Given the planId stuff is new and has the same issue, I think that
pushes me towards thinking now is better than later for fixing both.
I'm happy to adjust my patch unless you've started work
On Wed, May 21, 2025 at 09:34:02AM +0900, Michael Paquier wrote:
> On Tue, May 20, 2025 at 11:28:17PM +1200, David Rowley wrote:
> > Certainly, a bit late, yes. It basically requires implementing
> > unsigned types on the SQL level. I believe there are a few sunken
> > ships along that coastline, a
On Tue, May 20, 2025 at 10:35:39AM -0500, Sami Imseih wrote:
> 1/ this was missed in pg_stat_statements
> ./contrib/pg_stat_statements/pg_stat_statements.c:uint64
> saved_queryId = pstmt->queryId;
Right. Some greps based on "queryid" and "query_id" point that this
is the last reference to uin
On Tue, May 20, 2025 at 11:28:17PM +1200, David Rowley wrote:
> Certainly, a bit late, yes. It basically requires implementing
> unsigned types on the SQL level. I believe there are a few sunken
> ships along that coastline, and plenty of history in the archives if
> you want to understand some of
Supporting unsigned INTs will be valuable for more than just this
obviously, and if we do
ever have that capability, we would likely want to go that route. I
know I've been asked about
why queryIds could be negative more than a few times. Until then, I
think the patch being
suggested is reasonable
On Tue, 20 May 2025 at 18:12, Julien Rouhaud wrote:
> I don't think it was discussed, but why not go the other way, keep everything
> as uint64 and expose an uint64 datatype at the SQL level instead? That's
> something I actually want pretty often so I would be happy to have that
> natively, whet
On Tue, May 20, 2025 at 05:51:51PM +1200, David Rowley wrote:
> Given the planId stuff is new and has the same issue, I think that
> pushes me towards thinking now is better than later for fixing both.
>
> I'm happy to adjust my patch unless you've started working on it already.
Here you go with
On Tue, May 20, 2025 at 02:09:13PM +0900, Michael Paquier wrote:
> On Mon, May 19, 2025 at 08:43:25PM -0700, Lukas Fittl wrote:
> > Yeah, +1 to making this consistent across both query ID and the new plan
> > ID, and changing both to int64 internally seems best.
>
> Any thoughts from others? I'm O
On Tue, 20 May 2025 at 17:09, Michael Paquier wrote:
>
> On Mon, May 19, 2025 at 08:43:25PM -0700, Lukas Fittl wrote:
> > Yeah, +1 to making this consistent across both query ID and the new plan
> > ID, and changing both to int64 internally seems best.
>
> Any thoughts from others? I'm OK to take
On Mon, May 19, 2025 at 08:43:25PM -0700, Lukas Fittl wrote:
> Yeah, +1 to making this consistent across both query ID and the new plan
> ID, and changing both to int64 internally seems best.
Any thoughts from others? I'm OK to take the extra step of switching
both fields on HEAD and write a patc
On Mon, May 19, 2025 at 8:12 PM Michael Paquier wrote:
> On Tue, May 20, 2025 at 02:03:37PM +1200, David Rowley wrote:
> > Aside from the struct field types changing for Query.queryId,
> > PlannedStmt.queryId and PgBackendStatus.st_query_id, the
> > external-facing changes are limited to:
> >
> >
On Tue, May 20, 2025 at 02:03:37PM +1200, David Rowley wrote:
> Aside from the struct field types changing for Query.queryId,
> PlannedStmt.queryId and PgBackendStatus.st_query_id, the
> external-facing changes are limited to:
>
> 1. pgstat_report_query_id() now returns int64 instead of uint64
> 2
On Tue, 20 May 2025 at 03:05, Peter Eisentraut wrote:
> Or why not store query IDs as int64_t
> internally, too?
I had the same thought. Changing to int64 seems like a good and less
bug-prone tidy-up. I expected we ended up with uint64 as the previous
type was uint32, and uint64 is the natural se
FWIW, all the hash function SQL interfaces, \df hash*,
have this behavior in which the result is a signed (int/bigint),
but the internal representation of the hash is an unsigned (int/bigint).
I am not sure why a comment is needed specifically for pg_stat_statements
--
Sami Imseih
Amazon Web Ser
On 17.05.25 14:49, Michael Paquier wrote:
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 begi
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
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 think this is
intentional - the queryid is cast to int64 to ma
24 matches
Mail list logo
