Re: Hardening pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hardening pg_upgrade
Date
Msg-id 8355.1408651635@sss.pgh.pa.us
Whole thread Raw
In response to Hardening pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Hardening pg_upgrade
List pgsql-hackers
Bruce Momjian <bruce@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: run xmllint during build (was Re: need xmllint on borka)
Next
From: Magnus Hagander
Date:
Subject: Re: Hardening pg_upgrade