Re: Regress test might fail due to deadlock between domain and alter_table

Hi Alexander,

Hope that you are well.

I'm Osama Abdul Qader, currently working as an independent postgresql
contributor, I'm writing this email to express my interest in working with
you to fix this bug by producing the patch for it, I've already produced a
patch which was committed by Alvaro Hererra on September 8 [1].

I have reviewed the work of Jan Nidzwetzki [2].

Can't wait for morning (as I'm from Hyderabad, India and it's currently
01:50AM here) to work on the bug patch.

[1]:
https://github.com/postgres/postgres/commit/25b21c0bb712b615f22cf5fcc176764a416368bd
[2]: https://commitfest.postgresql.org/patch/7276/

With regards,
Osama Abdul Qader

On Thu, Oct 8, 2026 at 1:30 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:

> Hello hackers,
>
> I happened to observe an interesting failure of `make check` being
> executed concurrently against multiple databases:
> diff -U3 --minimal .../regress_input_27/expected/domain.out
> .../regress_output_27/results/domain.out
> --- .../expected/domain.out 2026-10-02 08:03:59.474274001 +0000
> +++ .../results/domain.out 2026-10-02 08:26:49.225597020 +0000
> @@ -1337,11 +1337,7 @@
> FROM information_schema.domain_constraints
> WHERE domain_name IN ('con', 'dom', 'pos_int', 'things'))
> ORDER BY constraint_name;
> - constraint_catalog | constraint_schema | constraint_name | check_clause
>
> ---------------------+-------------------+------------------+-------------------
> - regress027 | public | con_check | (VALUE > 0)
> - regress027 | public | meow | (VALUE < 11)
> - regress027 | public | pos_int_check | (VALUE > 0)
> - regress027 | public | pos_int_not_null | VALUE IS NOT
> NULL
> -(4 rows)
> -
> +ERROR: deadlock detected
> +DETAIL: Process 322216 waits for AccessShareLock on relation 1197300 of
> database 16411; blocked by process 322217.
> +Process 322217 waits for AccessExclusiveLock on relation 1197314 of
> database 16411; blocked by process 322216.
> +HINT: See server log for query details.
>
> I've managed to reproduce this with the attached patch:
> # diff -U3 .../src/test/regress/expected/alter_table.out
> .../src/test/regress/results/alter_table.out
> # --- .../src/test/regress/expected/alter_table.out 2026-10-07
> 12:53:24.843538437 -0400
> # +++ .../src/test/regress/results/alter_table.out 2026-10-07
> 14:58:08.602062642 -0400
> # @@ -4808,7 +4808,10 @@
> # (1 row)
> #
> # alter table attbl alter column a type numeric; -- someday this should
> work
> # -ERROR: cannot alter table "attbl" because column "atref.b" uses its
> row type
> # +ERROR: deadlock detected
> # +DETAIL: Process 2884690 waits for AccessExclusiveLock on relation
> 45440 of database 16384; blocked by process 2884685.
> # +Process 2884685 waits for AccessShareLock on relation 45437 of database
> 16384; blocked by process 2884690.
> # +HINT: See server log for query details.
> # alter table atref drop constraint atref_b_check;
> # create statistics atref_stat on ((b).a is not null) from atref;
> # alter table attbl alter column a type numeric; -- someday this should
> work
>
> That is, the deadlock occurs between
> "SELECT * FROM information_schema.check_constraint" /
> pg_get_constraintdef()
> and
> "alter table attbl alter column a type numeric;" /
> ATPostAlterTypeCleanup().
>
> Reproduced starting from 8319e5cb5.
>
> Best regards,
> Alexander