Re: pg_upgrade and extra_float_digits
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade and extra_float_digits |
Дата | |
Msg-id | 201005170109.o4H19jX02044@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade and extra_float_digits (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: pg_upgrade and extra_float_digits
|
Список | 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 по дате отправления: