Re: Hardening pg_upgrade

Bruce Momjian <bruce(at)momjian(dot)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