pg_upgrade test for binary compatibility of core data types
От | Justin Pryzby |
---|---|
Тема | pg_upgrade test for binary compatibility of core data types |
Дата | |
Msg-id | 20201206180248.GI24052@telsasoft.com обсуждение исходный текст |
Ответы |
Re: pg_upgrade test for binary compatibility of core data types
|
Список | pgsql-hackers |
I'm finally returning to this 14 month old thread: (was: Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12) On Tue, Oct 15, 2019 at 09:07:25AM +0200, Tomas Vondra wrote: > On Mon, Oct 14, 2019 at 11:41:18PM -0500, Justin Pryzby wrote: > > > > Perhaps it'd be worth creating a test for on-disk format ? > > > > Like a table with a column for each core type, which is either SELECTed from > > after pg_upgrade, or pg_dump output compared before and after. > > IMO that would be useful - we now have a couple of these checks for > different data types (line, unknown, sql_identifier), with a couple of > combinations each. And I've been looking if we do similar pg_upgrade > tests, but I haven't found anything. I mean, we do pg_upgrade the > cluster used for regression tests, but here we need to test a number of > cases that are meant to abort the pg_upgrade. So we'd need a number of > pg_upgrade runs, to test that. I meant to notice if the binary format is accidentally changed again, which was what happened here: 7c15cef86 Base information_schema.sql_identifier domain on name, not varchar. I added a table to the regression tests so it's processed by pg_upgrade tests, run like: | time make -C src/bin/pg_upgrade check oldsrc=`pwd`/11 oldbindir=`pwd`/11/tmp_install/usr/local/pgsql/bin I checked that if I cherry-pick 0002 to v11, and comment out old_11_check_for_sql_identifier_data_type_usage(), then pg_upgrade/test.sh detects the original problem: pg_dump: error: Error message from server: ERROR: invalid memory alloc request size 18446744073709551613 I understand the buildfarm has its own cross-version-upgrade test, which I think would catch this on its own. These all seem to complicate use of pg_upgrade/test.sh, so 0001 is needed to allow testing upgrade from older releases. e78900afd217fa3eaa77c51e23a94c1466af421c Create by default sql/ and expected/ for output directory in pg_regress 40b132c1afbb4b1494aa8e48cc35ec98d2b90777 In the pg_upgrade test suite, don't write to src/test/regress. fc49e24fa69a15efacd5b8958115ed9c43c48f9a Make WAL segment size configurable at initdb time. c37b3d08ca6873f9d4eaf24c72a90a550970cbb8 Allow group access on PGDATA da9b580d89903fee871cf54845ffa2b26bda2e11 Refactor dir/file permissions -- Justin
Вложения
В списке pgsql-hackers по дате отправления: