| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Test instability when pg_dump orders by OID |
| Date: | 2025-08-24 16:08:16 |
| Message-ID: | 20250824160816.06.nmisch@google.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Aug 24, 2025 at 11:50:01AM -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I wonder if it's worth adding support to CI to perform the cross-version
> > upgrade test. It'd be pretty easy to install all pgdg apt postgres packages to
> > the debian image, which then could be used as the source version...
I think catching this particular case would take more than that. It entails
running the latest v16 src/test/regress suite, capturing the dump of that into
$animal_root/upgrade.$animal/REL_16_STABLE/*.sql, and seeing the upgrade
failure of that dump having the latest v16 regression objects. I don't know
how to get there without a v16 source tree.
> I feel that that's the wrong tradeoff. CI should be expected to be
> fairly cheap, not to catch everything the buildfarm could catch.
It can always be non-default, like the mingw test.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2025-08-24 16:42:56 | Re: Non-text mode for pg_dumpall |
| Previous Message | Tom Lane | 2025-08-24 15:50:01 | Re: Test instability when pg_dump orders by OID |