Re: Test instability when pg_dump orders by OID
От | Noah Misch |
---|---|
Тема | Re: Test instability when pg_dump orders by OID |
Дата | |
Msg-id | 20250824160816.06.nmisch@google.com обсуждение исходный текст |
Ответ на | Re: Test instability when pg_dump orders by OID (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Test instability when pg_dump orders by OID
|
Список | pgsql-hackers |
On Sun, Aug 24, 2025 at 11:50:01AM -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.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.
В списке pgsql-hackers по дате отправления: