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/
