pgsql: In pg_upgrade, properly handle oids > 2^31 by using strtoul() in
In pg_upgrade, properly handle oids > 2^31 by using strtoul() internally
rather than atol().
Per report from Brian Hirt
Branch
------
master
Details
-------
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=9340fb80b1dba5528c0d16b24985369659a19377
Modified Files
--------------
contrib/pg_upgrade/controldata.c | 30 +++++++++++++++---------------
contrib/pg_upgrade/info.c | 8 ++++----
contrib/pg_upgrade/pg_upgrade.h | 2 ++
contrib/pg_upgrade/relfilenode.c | 4 ++--
contrib/pg_upgrade/util.c | 12 ++++++++++++
5 files changed, 35 insertions(+), 21 deletions(-)
Bruce Momjian <bruce@momjian.us> writes:
In pg_upgrade, properly handle oids > 2^31 by using strtoul() internally
rather than atol().
It would be a lot better if this code adhered to the project-standard
coding convention of defining and using an atooid() macro for the
purpose of converting text representations of OIDs to bits.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
In pg_upgrade, properly handle oids > 2^31 by using strtoul() internally
rather than atol().It would be a lot better if this code adhered to the project-standard
coding convention of defining and using an atooid() macro for the
purpose of converting text representations of OIDs to bits.
OK, I used your idea for conversion directly to oid from the system
catalogs, patch attached. All the pg_controldata returned integers are
defined as uint32 in pg_upgrade. Should I use atooid() for some of them
and define some of them as OID? I thought that might just add more
confusion. On a quick look, it seems only chkpnt_nxtoid is an oid, but
I am not sure.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
/rtmp/difftext/x-diffDownload+8-6
Bruce Momjian <bruce@momjian.us> writes:
OK, I used your idea for conversion directly to oid from the system
catalogs, patch attached. All the pg_controldata returned integers are
defined as uint32 in pg_upgrade. Should I use atooid() for some of them
and define some of them as OID?
No, I don't think so --- most of them are not in fact OIDs. Probably
best to follow what pg_control.h declares them as.
regards, tom lane