Re: Parallel Apply

>
> Thanks for the contact. Here is an updated version.
>
> The version number now becomes v27 by the internal reviews. I adjusted each
> patches to work well and pass tests, and fixed test codes to extract the
> dependent transaction correctly.

I found that dependency tracking via foreign keys (get_local_fkeys(),
relation.c) never does anything for a self-referencing foreign key,
letting a transaction that is applied directly by the leader race
ahead of an earlier, still-in-flight parallel-applied transaction it
actually depends on, and hit a foreign key violation that correct
dependency tracking should have prevented.
get_local_fkeys() classifies each FK constraint on a table with:
if (con->confrelid == relid)
trig_type = RI_TRIGGER_PK;
else if (con->conrelid == relid)
trig_type = RI_TRIGGER_FK;

For a self-referencing FK, conrelid and confrelid are the same OID
(the table references itself), so both conditions are true and the
first one always wins. The constraint ends up recorded only in
entry->local_refkeys (as if the table were purely the referenced/PK
side of some other table's FK), and never in entry->local_fkeys (the
referencing/FK side). check_and_record_fkey_dependency() (worker.c)
only ever consults local_fkeys to decide whether an incoming row's FK
value must wait for an earlier transaction that inserted the
referenced key -- so for a self-referencing constraint, that check is
not merely unreliable, it structurally never runs at all.

The attached patch has a test case to reproduce this issue.

Regards,
Vignesh