Tuple insert missing query in ongoing transaction

Dear Gurus,

I know this is the typical case of transaction use, I just seem to lack the
appropriate education of what exactly happens and whether I may be able to
detect it.

I have two queries, one affecting the other.

1. INSERT INTO barcode.
A BEFORE INSERT/UPDATE trigger checks if there's an appropriate tuple in
table "shift" for this tuple (matching day, shift-of-the-day and workplace)
and denormalizes fields.

2. INSERT INTO shift.
An AFTER INSERT/UPDATE/DELETE trigger updates rows in table barcode, forcing
the abovementioned check for shift.

The second one is a long process, taking about 20 sec to finish. Imagine the
following scenario:

x:xx:00 INSERT INTO shift.
Transaction "S" begins.
It updates several rows, but not the not-yet-inserted row.
x:xx:10 INSERT INTO barcode (... appropriate for above-inserted shift ...)
Transaction "B" begins.
It checks but does not find the corresponding shift.
x:xx:11 Transaction "B" ends.
x:xx:20 Transaction "S" ends.

In such scenarios, sometimes we get "Deadlock detected." That's OK since the
transactions actually cross each other's way.

But not always. In about 100 inserts, now we have the first case that did
not show any trace of that something went wrong.

1. Is there a way to detect such "crossing" transactions?
2. Is there a thorough article on deadlocks, how and when do they happen?
3. Maybe a section of the postgresql doc clarifying when do tuples get locked?

TIA,

--
G.