Implicit conversion from int64 to int32 when calling hash_get_num_entries
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/
Attachments:
v1-0001-Use-int64-for-number-of-entries-in-pg_stat_statem.patchtext/x-patch; charset=US-ASCII; name=v1-0001-Use-int64-for-number-of-entries-in-pg_stat_statem.patchDownload+6-7
0001-pg_stat_statements-explicitly-convert-number-of-entr.patchtext/x-patch; charset=US-ASCII; name=0001-pg_stat_statements-explicitly-convert-number-of-entr.patchDownload+8-3
On 13 Jul 2026, at 17:00, Karina Litskevich <litskevichkarina@gmail.com> wrote:
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.
Agreed, I think we should make sure to do this once beta2 has shipped for the
next beta release.
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.
Given the likelihood of an issue in backbranches, we could also only apply for
v19 and leave the backbranches.
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.
Makes sense.
--
Daniel Gustafsson
Thank you for the review, Daniel.
On Mon, Jul 13, 2026 at 11:36 PM Daniel Gustafsson <daniel@yesql.se> wrote:
Given the likelihood of an issue in backbranches, we could also only apply for
v19 and leave the backbranches.
I'm okay with that too.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/