pg_upgrade's check.c contains a function called
check_for_isn_and_int8_passing_mismatch. If the float8 pass-by-value
values differ between the old and new clusters, which is likely to
happen on Windows 64 because of cf376a4ad, and if the old cluster
contains any databases which contain functions from '$libdir/isn',
then it fails the upgrade. The comments say this:
* contrib/isn relies on data type int8, and in 8.4 int8 can now be passed* by value. The schema dumps the CREATE
TYPEPASSEDBYVALUE setting so* it must match for the old and new servers.
There are a couple of things that bother me here:
1. The check is restricted to isn, but the issue isn't. Presumably,
any datatype that is passed either by value or by reference depending
on whether float8 is passed-by-value has the same issue. isn is the
only module in core that has this issue, but there could be
third-party modules with the same issue. I'm not sure there's
anything we can do about that, but it's troublesome.
2. If pg_dump knew that we were trying to dump a type of this sort, it
could easily emit an incantation that would work everywhere. Commit
3f936aacc introduced a LIKE = typename syntax that suits this problem
perfectly, and changed the scripts for contrib/isn to use it. But
pg_dump can't use that syntax, because there's no catalog state to
record whether we want new typbyval = old typbyval or whether we
instead want new typbyval = new cluster's float8-pass-by-value.
Is it worth trying to fix this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
