What makes me suspect it's a lock on the parent table is the word "ShareLock" in the logs. A SELECT ... FOR UPDATE statement shouldn't place that type of lock on the table it's selecting.
This looks 100% like a normal, multi-row deadlock situation. The CONTEXT shows it is a row-level problem:
CONTEXT: while locking tuple (7,15) in relation “paiyroll_endpoint”
The ShareLocks are on the transaction, because each backend is waiting for the other to finish their transaction, and thus release the lock(s) it may have.
If you implement Tom's suggestion, I think you will find that this is a classic failing to lock the rows in the same order problem.
