Horton

Re: pg_dump versus ancient server versions

Andrew Dunstan <andrew@dunslane.net>

View thread View on postgr.es
From: Andrew Dunstan <andrew@dunslane.net>
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-25T20:29:11Z
Lists: pgsql-hackers 
On 10/25/21 13:06, Andres Freund wrote:
> 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.


Right now the server will only accept results for something in
branches_of_interest.txt. So we would need to modify that.


I tend to agree that we don't need a whole lot of cross platform testing
here.


>
>
>> 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.
>
>

If you have removed the work tree (with the "rm_worktrees => 1" setting)
then it restores it by doing a checkout. It then does a "git fetch", and
then as you say looks to see if there is anything new. If you know of a
better way to manage it then please let me know. On crake (which is
actually checking out four different repos) the checkout step typically
takes one or two seconds.


Copying the work tree can take a few seconds - to avoid that on
Unix/msys use vpath builds.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Commits

  1. Remove psql support for server versions preceding 9.2.

  2. Clean up some more freshly-dead code in pg_dump and pg_upgrade.

  3. Remove pg_dump's --no-synchronized-snapshots switch.

  4. Remove pg_upgrade support for upgrading from pre-9.2 servers.

  5. Remove pg_dump/pg_dumpall support for dumping from pre-9.2 servers.

  6. Suppress -Warray-bounds warning in 9.2's xlog.c.

  7. Suppress -Wformat-overflow warnings in 9.2's xml.c.

  8. Disable -Wsometimes-uninitialized warnings in the 9.2 branch.

  9. Fix function return type confusion

  10. Fix compiler warning

  11. Silence another gcc 11 warning.

  12. Suppress uninitialized-variable warning in guc.c.

  13. Suppress -Warray-parameter warnings in pgcrypto/sha2.c.

  14. Reformat imath.c macro to remove -Wmisleading-indentation warnings.

  15. Clean up compilation warnings coming from PL/Perl with clang-12~

  16. Make ecpg's rjulmdy() and rmdyjul() agree with their declarations.

  17. Use -Wno-format-truncation and -Wno-stringop-truncation, if available.

  18. Make pg_upgrade's test.sh less chatty.

  19. Add checks for valid multibyte character length in UtfToLocal, LocalToUtf.

  20. Use return instead of exit() in configure

  21. Add support for Visual Studio 2019 in build scripts