From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_dump versus ancient server versions |
Date: | 2021-10-25 17:06:57 |
Message-ID: | 20211025170657.ekufa7urdcyzpgdm@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-10-25 10:23:40 -0400, Tom Lane wrote:
> Also, I concur with Andrew's point that we'd really have to have
> buildfarm support. However, this might not be as bad as it seems.
> In principle we might just need to add resurrected branches back to
> the branches_to_build list. Given my view of what the back-patching
> policy ought to be, a new build in an old branch might only be
> required a couple of times a year, which would not be an undue
> investment of buildfarm resources.
FWIW, if helpful I could easily specify a few additional branches to some of
my buildfarm animals. Perhaps serinus/flaviventris (snapshot gcc wo/w
optimizations) so we'd see problems coming early? I could also add
recent-clang one.
I think doing this to a few designated animals is a better idea than wasting
cycles and space on a lot of animals.
> It seems like a fresh checkout from the repo would be little more expensive
> than the current copy-a-checkout process.)
I haven't looked in detail, but from what I've seen in the logs the
is-there-anything-new check is already not cheap, and does a checkout / update
of the git directory.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-10-25 17:09:43 | Re: pg_dump versus ancient server versions |
Previous Message | Robert Haas | 2021-10-25 17:01:13 | Re: parallelizing the archiver |