Bruce Momjian <br...@momjian.us> writes:
> Specifically, the first attached patch causes pg_upgrade_support
> functions to throw errors when called by a backend that is not in binary
> upgrade mode. (This seems like a good safety measure.)
Agreed about that part.
> Second, and
> more importantly, the patch prevents automatic oid assignment when in
> binary upgrade mode, except for temporary objects. This is to help
> guarantee that system-assigned oids do not conflict with preserved oids.
> I had to make an exception for temporary tables because pg_upgrade uses
> temporary tables to collect schema information.
This seems like a bad idea. If you are going to have such an off-switch
at all (which I'm not sure I buy the need for), it should not have holes
in it.
> I tried writing the
> query to use CTEs (second patch), but I would then have to have one
> query for 8.3, which doesn't support CTEs, and another for 8.4+, plus
> the CTE query was more complex than I liked. Another idea would be to
> drop 8.3 support (and remove lots of code to support that), but the
> recent large increase in the number of people upgrading from 8.4 makes
> that unattractive. (8.3 did use a different timestamp storage format
> though.)
I vote for discarding 8.3 support in pg_upgrade. There are already enough
limitations on pg_upgrade from pre-8.4 to make it of questionable value;
if it's going to create problems like this, it's time to cut the rope.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
