Re: PATCH: Configurable file mode mask
От | David Steele |
---|---|
Тема | Re: PATCH: Configurable file mode mask |
Дата | |
Msg-id | 8ca3a7eb-95da-fd32-78d9-888ebc58615b@pgmasters.net обсуждение исходный текст |
Ответ на | Re: PATCH: Configurable file mode mask (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: PATCH: Configurable file mode mask
Re: PATCH: Configurable file mode mask |
Список | pgsql-hackers |
On 1/20/18 5:47 PM, Michael Paquier wrote: > On Fri, Jan 19, 2018 at 06:54:23PM -0300, Alvaro Herrera wrote: >> Peter Eisentraut wrote: >> If the only problem is that buildfarm would run tests twice, then I >> think we should just press forward with this regardless of that: it >> seems a chicken-and-egg problem, because buildfarm cannot be upgraded to >> use some new test method if the method doesn't exist yet. As a >> solution, let's just live with some run duplication for a period until >> the machines are upgraded to a future buildfarm client code. It also appears that the TAP tests don't have the infrastructure to be able to run pg_ugrade properly, per below. > The main complain I received about this move of the pg_upgrade tests to > be a TAP one is that they don't support easily cross-major version > upgrades, removing some abilities to what a developer or the builfarm > can actually do. Unless I read it wrong the buildfarm is not doing cross-version upgrades, but a developer/user can do so manually using the same script? > Making this possible would require first some > refactoring of PostgresNode.pm so as a node is aware of the binary paths > it uses to be able to manipulate multiple instances with different > install paths at the same time. Any idea of what the LOE would be for that? Thanks, -- -David david@pgmasters.net
Вложения
В списке pgsql-hackers по дате отправления: