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

Hi,

I'm currently investigating a reproducible deadlock involving concurrent
regression tests (alter_table and domain), starting from commit 8319e5cb5.

While setting up a clean PostgreSQL 20devel environment to reproduce the
issue, I ran into a separate bootstrap failure that I'm having trouble
explaining.

I rebuilt and installed the current source tree, and verified that both
binaries report PostgreSQL 20devel. I also verified that bthandler() in
src/backend/access/nbtree/nbtree.c returns a static IndexAmRoutine, and
that the generated FMGR table maps OID 330 to bthandler.

However, a completely fresh cluster fails during initdb:

$ rm -rf ~/pgdata-repro
$ ~/pg-install/bin/initdb -D ~/pgdata-repro

running bootstrap script ...
FATAL: index access method handler function 330 did not return an
IndexAmRoutine struct
PANIC: cannot abort transaction 1, it was already committed
Aborted (core dumped)
initdb: removing data directory "/home/osama/pgdata-repro"

The relevant check appears to be in src/backend/access/index/amapi.c:

datum = OidFunctionCall0(amhandler);
routine = (const IndexAmRoutine *) DatumGetPointer(datum);

if (routine == NULL || !IsA(routine, IndexAmRoutine))
elog(ERROR, "index access method handler function %u did not
return an IndexAmRoutine struct",
amhandler);

I have not modified nbtree.c, and the generated catalog contains:

330 bthandler ... bthandler

and fmgrtab.c contains:

{ 330, 1, true, false, "bthandler", bthandler },

I initially suspected a stale build, but I forced a rebuild of the nbtree
code and backend, reinstalled, and the failure persisted.

Could you point me toward what might cause bthandler() to fail the IsA(routine,
IndexAmRoutine) check during bootstrap?

I want to make sure my development build is sound before continuing with
the deadlock reproduction.

Thanks,
Osama Abdul Qader

On Thu, Oct 8, 2026 at 1:15 PM Osama Abdul Qader <
osamaabdulqader(dot)cs(at)gmail(dot)com> wrote:

> Hi Alexander,
>
> Sure, I'll cooperate with you and also the senior hacker who is in charge
> of committing the patches, surely it's a nice day to work with you.
>
> Let us solve these issues and make our work scream in PostgreSQL commit
> history.
>
> With best regards,
> Osama Abdul Qader
>
> On Thu, Oct 8, 2026 at 10:30 AM Alexander Lakhin <exclusion(at)gmail(dot)com>
> wrote:
>
>> Hello Osama,
>>
>> [ writing this off-list to minimize noise ]
>>
>> 07.10.2026 23:24, Osama Abdul Qader wrote:
>>
>> 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.
>>
>>
>> I'm not a committer (unlike Alvaro), so I think you would need to
>> cooperate with some of senior hackers who will eventually push the
>> patch anyway. To me, it looks like a tricky issue and I have no idea yet
>> how to fix it properly, so if you want to work on this, please step in.
>>
>> Looking forward to your patch or deeper investigation on the mailing list.
>>
>> Best regards,
>> Alexander
>>
>