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 201005170109.o4H19jX02044@momjian.us
Whole thread Raw
In response to Re: pg_upgrade and extra_float_digits  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_upgrade and extra_float_digits
List pgsql-hackers
Andrew Dunstan wrote:
> > 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.  You can _load_ that dump file into an
> > unmodified old cluster and test just fine.  I will write up some
> > instructions in the next few days.
> >
> >   
> 
> You are missing the point I was making. A buildfarm run does not 
> normally have available to it any binaries for a version other that the 
> one it is building. There is no notion of a multi-branch buildfarm run. 
> Each run is for a particular branch and is a separate miracle.  So I'm 
> not concerned about the structure of the dump file but about what will 
> be used to load it into an old cluster during a buildfarm run.

Thank you.  I understand now.

Imagine finding out on the build farm right away when we break binary
compatibility --- that would be cool.  However, that might be overkill. 
My testing seems to be working just fine.  In fact the only diff I see
is:
< CREATE PROCEDURAL LANGUAGE plpgsql;---> CREATE OR REPLACE PROCEDURAL LANGUAGE plpgsql;

and that is a known change.  I might end up adding my regression dump
files to our ftp site (400k for each major version), and just having
people use them for testing.

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


pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Next
From: Florian Pflug
Date:
Subject: Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle