Hi,
On 2019-08-16 09:44:15 -0700, Hadi Moshayedi wrote:
> It seems that sometimes when DELETE cascades to referencing tables we fail
> to acquire locks on replica identity index.
>
> To reproduce, set wal_level to logical, and run 1.sql.
>
> I can look into this, but I thought first I should send it here in case
> someone who is more familiar with these related functions can solve it
> quickly.
I suspect this "always" has been broken, it's just that we previously
didn't have checks in place that detect these cases. I don't think it's
likely to cause actual harm, due to the locking on the table itself when
dropping indexes etc. But we still should fix it.
The relevant code is:
/*
* If there are indices on the result relation, open them and
save
* descriptors in the result relation info, so that we can add
new
* index entries for the tuples we add/update. We need not do
this
* for a DELETE, however, since deletion doesn't affect
indexes. Also,
* inside an EvalPlanQual operation, the indexes might be open
* already, since we share the resultrel state with the original
* query.
*/
if (resultRelInfo->ri_RelationDesc->rd_rel->relhasindex &&
operation != CMD_DELETE &&
resultRelInfo->ri_IndexRelationDescs == NULL)
ExecOpenIndices(resultRelInfo,
node->onConflictAction
!= ONCONFLICT_NONE);
I'm not quite sure what the best way to fix this would be however. It
seems like a bad idea to make locking dependent on wal_level, but I'm
also not sure we want to incur the price of locking one more table to
every delete on a table with a primary key?
Greetings,
Andres Freund
