Re: pg_upgrade and extra_float_digits
От | Andrew Dunstan |
---|---|
Тема | Re: pg_upgrade and extra_float_digits |
Дата | |
Msg-id | 4BF0950B.5090002@dunslane.net обсуждение исходный текст |
Ответ на | Re: pg_upgrade and extra_float_digits (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: pg_upgrade and extra_float_digits
|
Список | pgsql-hackers |
Bruce Momjian wrote: > Andrew Dunstan wrote: > >>>> Eventually the idea would be to have the build farm run such tests (with >>>> a properly created dump file) so we can learn quickly if the backend >>>> data format is changed. >>>> >>>> >>> If we're thinking of doing that, it would be better to back-patch the >>> change that allowed '3'. >>> >>> >>> >>> >> Yeah. >> >> 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. I'd have to work out a way of stashing the >> binaries from a build on one branch for use in the pg_upgrade tests in >> the run on another branch. It's doable but could get messy. >> > > 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. cheers andrew
В списке pgsql-hackers по дате отправления: