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  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade and extra_float_digits
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle