Re: Extracting cross-version-upgrade knowledge from buildfarm client
От | Tom Lane |
---|---|
Тема | Re: Extracting cross-version-upgrade knowledge from buildfarm client |
Дата | |
Msg-id | 3573464.1674056007@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Extracting cross-version-upgrade knowledge from buildfarm client (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Extracting cross-version-upgrade knowledge from buildfarm client
Re: Extracting cross-version-upgrade knowledge from buildfarm client |
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > fairwren and drongo are clean except for fairywren upgrading 9.6 to 11. > This appears to be a longstanding issue that the fuzz processing was > causing us to ignore. See for example > <https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=fairywren&dt=2022-09-01%2018%3A27%3A28&stg=xversion-upgrade-REL_10_STABLE-REL_11_STABLE> Interesting. I suspected that removing the fuzz allowance would teach us some things we hadn't known about. > I propose to add this to just the release 11 AdjustUpgrade.pm: > # float4 values in this table on Msys can have precision differences > # in representation between old and new versions > if ($old_version < 10 && $dbnames{contrib_regression_btree_gist} && > $^O eq 'msys') > { > _add_st($result, 'contrib_regression_btree_gist', > 'drop table if exists float4tmp'); > } Seems reasonable (but I wonder if you don't need "$old_version < 11"). A nicer answer would be to apply --extra-float-digits=0 across the board, but pre-v12 pg_dump lacks that switch. regards, tom lane
В списке pgsql-hackers по дате отправления: