Re: pg_upgrade and extra_float_digits - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade and extra_float_digits
Date
Msg-id 201005171011.o4HAB7S03108@momjian.us
Whole thread Raw
In response to Re: pg_upgrade and extra_float_digits  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_upgrade and extra_float_digits
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Andrew Dunstan wrote:
> >> It's going to require some fancy dancing to get the buildfarm to do it. 
> >> Each buildfarm run is for a specific branch, and all the built artefacts 
> >> are normally thrown away.
> 
> > Uh, that is not actually a problem.  You just need to set
> > extra_float_digits=-3 to create the dump file, which is only done once
> > for each major version.
> 
> Wrong.  In the first place, we're not going to start carrying something
> as large as a pg_dump of the regression database as part of the source
> code for the buildfarm.  Even if we wanted to, it wouldn't work because
> the results aren't platform-independent --- there are float differences
> and probably row ordering differences to worry about.  In the second

Oh, yea.

> place, it won't "only be done once", unless you imagine that we never
> change the regression tests for back branches; a casual perusal of the
> CVS logs will disprove that idea.

Well, it doesn't have to match the regression test output exactly --- it
just has to be a valid sample.  I never run the regression tests as part
of my testing --- I only load my fixed pg_dump output into the old
database and dump them from the new, and diff.

> The only thing that's really going to work here is to generate the dump
> on the fly.

Well, to do it on the fly, you need to:
use $libdir for regression .so files, not absolute pathschange CREATE OR REPLACE LANGUAGE to simple CREAtE for 8.4run
ittwice to fix inheritance COPY column orderingdeal with extra_float_digits
 

That sounds tricky.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Keepalive for max_standby_delay
Next
From: Robert Haas
Date:
Subject: Re: Stefan's bug (was: max_standby_delay considered harmful)