With after triggers the crash does't reproduce because they don't create reentrancy in RI_Fkey_cascade_del.
There are use cases in which a before delete trigger could want to delete other rows, for example if you have a function that accesses the row by id to free some external resource or mark something in other tables, you need the row to be alive, that means it can't be an after trigger, and nothing prevents you for using before triggers to do cleanup.
Also, you don't normally delete rows recursively from a self referential table like the naive example in the test case, you normally want to do something like table inheritance, where 2 tables inherit from a parent table, and one references the other one, it is self-referential with respect to the parent.
If BEFORE DELETE triggers should not delete rows, i think postgres should explicitly throw a clean exception, something like "ERROR: Cannot delete rows in before delete trigger".
Else, we should fix this bug.
Ultimately, I think the postgres team should decide which of the 2 approaches to take.
I can give time and work to fix the segfault.
Thanks,
