postgresql fails to build with Python 3.10.0b1: PATH="/builddir/build/BUILD/postgresql-13.2/tmp_install/usr/bin:$PATH" LD_LIBRARY_PATH="/builddir/build/BUILD/postgresql-13.2/tmp_install/usr/lib64" ../../../src/test/regress/pg_regress --temp-instance=./tmp_check --inputdir=. --bindir= --dbname=pl_regression python3/plpython_schema python3/plpython_populate python3/plpython_test python3/plpython_do python3/plpython_global python3/plpython_import python3/plpython_spi python3/plpython_newline python3/plpython_void python3/plpython_call python3/plpython_params python3/plpython_setof python3/plpython_record python3/plpython_trigger python3/plpython_types python3/plpython_error python3/plpython_ereport python3/plpython_unicode python3/plpython_quote python3/plpython_composite python3/plpython_subtransaction python3/plpython_transaction python3/plpython_drop ============== creating temporary instance ============== ============== initializing database system ============== ============== starting postmaster ============== running on port 64466 with PID 20008 ============== creating database "pl_regression" ============== CREATE DATABASE ALTER DATABASE ============== running regression test queries ============== test python3/plpython_schema ... ok 23 ms test python3/plpython_populate ... ok 15 ms test python3/plpython_test ... ok 30 ms test python3/plpython_do ... ok 25 ms test python3/plpython_global ... ok 26 ms test python3/plpython_import ... ok 43 ms test python3/plpython_spi ... ok 50 ms test python3/plpython_newline ... ok 26 ms test python3/plpython_void ... ok 27 ms test python3/plpython_call ... ok 30 ms test python3/plpython_params ... ok 28 ms test python3/plpython_setof ... ok 32 ms test python3/plpython_record ... ok 39 ms test python3/plpython_trigger ... ok 69 ms test python3/plpython_types ... ok 76 ms test python3/plpython_error ... ok 43 ms test python3/plpython_ereport ... ok 34 ms test python3/plpython_unicode ... ok 29 ms test python3/plpython_quote ... ok 26 ms test python3/plpython_composite ... ok 44 ms test python3/plpython_subtransaction ... FAILED 45 ms test python3/plpython_transaction ... ok 40 ms test python3/plpython_drop ... ok 15 ms ============== shutting down postmaster ============== ======================= 1 of 23 tests failed. ======================= The differences that caused some tests to fail can be viewed in the file "/builddir/build/BUILD/postgresql-13.2/src/pl/plpython/regression.diffs". A copy of the test summary that you see above is saved in the file "/builddir/build/BUILD/postgresql-13.2/src/pl/plpython/regression.out". I don't think the log actually contains the problem thou. A mockbuild might be required to see the content of above-mentioned regression.diffs. For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-x86_64/02175459-postgresql/ For all our attempts to build postgresql with Python 3.10, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/postgresql/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.10: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/ Let us know here if you have any questions. Python 3.10 will be included in Fedora 35. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.10. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
This is caused by python 3.10 having slightly different traceback: cat /var/lib/mock/fedora-rawhide-python310/root/builddir/build/BUILD/postgresql-13.2/src/pl/plpython/regression.diffs diff -U3 /builddir/build/BUILD/postgresql-13.2/src/pl/plpython/expected/python3/plpython_subtransaction.out /builddir/build/BUILD/postgresql-13.2/src/pl/plpython/results/python3/plpython_subtransaction.out --- /builddir/build/BUILD/postgresql-13.2/src/pl/plpython/expected/python3/plpython_subtransaction.out 2021-05-11 17:05:24.116431883 +0200 +++ /builddir/build/BUILD/postgresql-13.2/src/pl/plpython/results/python3/plpython_subtransaction.out 2021-05-11 17:05:26.689459542 +0200 @@ -224,8 +224,8 @@ SELECT subtransaction_exit_subtransaction_in_with(); ERROR: ValueError: this subtransaction has already been exited CONTEXT: Traceback (most recent call last): - PL/Python function "subtransaction_exit_subtransaction_in_with", line 3, in <module> - s.__exit__(None, None, None) + PL/Python function "subtransaction_exit_subtransaction_in_with", line 2, in <module> + with plpy.subtransaction() as s: PL/Python function "subtransaction_exit_subtransaction_in_with" -- Make sure we don't get a "current transaction is aborted" error SELECT 1 as test; We'll need to look at how to not depend on the message itself.
(In reply to Honza Horak from comment #1) > This is caused by python 3.10 having slightly different traceback: Bleah. We've dealt with some other inter-version message differences by generating alternate expected-files (see the expected/foo_N.out files under src/pl/plpython). Not sure whether that's the most expedient answer here. I'll bring this up upstream.
(In reply to Tom Lane from comment #2) > (In reply to Honza Horak from comment #1) > > This is caused by python 3.10 having slightly different traceback: > > Bleah. We've dealt with some other inter-version message differences > by generating alternate expected-files (see the expected/foo_N.out > files under src/pl/plpython). Not sure whether that's the most > expedient answer here. I'll bring this up upstream. Thanks. I was so far thinking about rewriting the function python code by adding try/except and use an explicit exception text, so it returns the same text with all python versions. I haven't managed to try that yet.
(In reply to Honza Horak from comment #3) > Thanks. I was so far thinking about rewriting the function python code by > adding try/except and use an explicit exception text, so it returns the same > text with all python versions. I haven't managed to try that yet. It seems to do the trick: https://src.fedoraproject.org/rpms/postgresql/pull-request/31
Upstream discussion: https://www.postgresql.org/message-id/853083.1620749597%40sss.pgh.pa.us
Patch applied and built in F35. Let us know if the component does not compile properly with Python 3.10.