longfin and tamandua aren't too happy but I'm not sure why
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Dilip Kumar <dilipbalaut@gmail.com>
Date: 2022-09-27T18:55:18Z
Lists: pgsql-hackers
Hi,
longfin and tamandua recently begun failing like this, quite possibly
as a result of 05d4cbf9b6ba708858984b01ca0fc56d59d4ec7c:
+++ regress check in contrib/test_decoding +++
test ddl ... FAILED (test process exited with
exit code 2) 3276 ms
(all other tests in this suite also fail, probably because the server
crashed here)
The server logs look like this:
2022-09-27 13:51:08.652 EDT [37090:4] LOG: server process (PID 37105)
was terminated by signal 4: Illegal instruction: 4
2022-09-27 13:51:08.652 EDT [37090:5] DETAIL: Failed process was
running: SELECT data FROM
pg_logical_slot_get_changes('regression_slot', NULL, NULL,
'include-xids', '0', 'skip-empty-xacts', '1');
Both animals are running with -fsanitize=alignment and it's not
difficult to believe that the commit mentioned above could have
introduced an alignment problem where we didn't have one before, but
without a stack backtrace I don't know how to track it down. I tried
running those tests locally with -fsanitize=alignment and they passed.
Any ideas on how to track this down?
--
Robert Haas
EDB: http://www.enterprisedb.com
Commits
-
meson: Split 'main' suite into 'regress' and 'isolation'
- a5ac3e76fe96 16.0 landed
-
ci: Add 32bit build and test
- ccf36ea2580f 16.0 landed
-
Fix InitializeRelfilenumberMap for 05d4cbf9b6ba708858984b01ca0fc56d59d4ec7c
- 6af082723277 16.0 landed
-
Fix alignment problems with SharedInvalSmgrMsg.
- 0222be137188 16.0 landed
-
In BufTagGetForkNum, cast to the correct type.
- 0aaa7cf6989e 16.0 landed
-
Increase width of RelFileNumbers from 32 bits to 56 bits.
- 05d4cbf9b6ba 16.0 cited
-
Harden pg_filenode_relation test against concurrent DROP TABLE.
- f3fdd257a430 9.5.0 cited