Implicit conversion from int64 to int32 when calling hash_get_num_entries

From: Karina Litskevich <litskevichkarina(at)gmail(dot)com>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Implicit conversion from int64 to int32 when calling hash_get_num_entries
Date: 2026-07-13 15:00:47
Message-ID: CACiT8iYTkc33YWaA2D3t51Y5s=GqBO7T1zX7bkpSmet2njcLLw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers!

In 13b935cd hash_get_num_entries was changed to return int64 instead of
long. I noticed that there is one more usage of it in pg_stat_statements
that should be cleaned up. There hash_get_num_entries's return value is
assigned to int32, so it was technically a defect even before 13b935cd.
That's also probably a reason why it was missed. There are some other
hash_get_num_entries usages in backend where hash_get_num_entries's
return value is assigned to int32, but I was going to look into them
later.

In practice number of entries in pgss_hash should not exceed pgss_max,
and we should be okay while pgss_max fits int32.

Simply changing num_entries to int64 leads to the change of the file
header format. I suggest changing num_entries to int64 in PG19 and
later, because it wasn't released yet, and pgss files generated by
another major version are considered to be incompatible anyway. See
the v1 patch attached.

Doing the same in already released versions would require increasing
PGSS_FILE_HEADER version. I don't think it's worth it, so for older
versions I suggest just adding a comment, a check, and an explicit
conversion to int32. See the second patch attached.

Another minor problem I noticed was the definition of pgver. It's
defined as int32, but used as uint32. So I fixed it in both patches.

Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/

Attachment Content-Type Size
v1-0001-Use-int64-for-number-of-entries-in-pg_stat_statem.patch text/x-patch 2.1 KB
0001-pg_stat_statements-explicitly-convert-number-of-entr.patch text/x-patch 1.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-07-13 15:06:30 Re: Report oldest xmin source when autovacuum cannot remove tuples
Previous Message Henson Choi 2026-07-13 14:34:32 Re: Row pattern recognition