But how do they work w.r.t. transactions, as truncate table requires an exclusive lock on table t...?

I think this sequence could occur with:

ConnM: user connection to mirror

ConnP: user connection to primary

ConnM: starts doing: SELECT MAX ( inserted_at ) FROM t; -- this will get a shared schema lock on t

ConnP: TRUNCATE TABLE t; -- succeeds immediately

Mirror now attempts to apply "TRUNCATE TABLE t" - and blocks on shared schema lock. If it remains blocked for a few seconds, the Mirror will rollback ConnM, resulting in your error

If the "SELECT MAX ( inserted_at ) FROM t" always takes less than a second on the mirror, then off the top of my head, I can't think of the exact sequence that can cause this error.

It may not be (just) TRUNCATE, here's a simple repro...

--------------------------------------
-- dbisql on primary...
SELECT @@VERSION;
-- 16.0.0.2419
BEGIN
   DROP TABLE t;
   EXCEPTION WHEN OTHERS THEN
END;
CREATE TABLE t (
   pkey         BIGINT NOT NULL DEFAULT AUTOINCREMENT PRIMARY KEY,
   inserted_at  TIMESTAMP NOT NULL DEFAULT CURRENT TIMESTAMP,
   padding      VARCHAR ( 1000 ) NOT NULL );
CHECKPOINT;
WAITFOR DELAY '00:00:10';
SELECT CURRENT TIMESTAMP, ' Step 1 done';

--------------------------------------
-- dbisql on secondary...
-- user waits for "Step 1" to appear on primary
WAITFOR DELAY '00:00:10';
SELECT CURRENT TIMESTAMP, ' Step 2 started';
SELECT MAX ( inserted_at ) FROM t;
-- everything looks ok

--------------------------------------
-- dbisql on primary... repeat

--------------------------------------
-- dbisql on secondary... repeat
-- result may be funky, with this in Messages tab:

Could not execute statement.

Rollback occurred due to deadlock during prefetch
SQLCODE=-684, ODBC 3 State="40001"
Line 4, column 1
(Continuing after error)
Execution time: 0.002 seconds

Volker is correct. Read only connections can and do acquire locks on a mirror or copy node (they must). They will always acquire at least shared schema locks when they reference any table.

Note that there doesn't need to be a deadlock to get the "Rollback occurred due to deadlock during prefetch" error. Operations that were committed to the primary need to be applied to the mirror and copy node, and if attempting to apply these operations block for a few seconds (not necessarily deadlock), you'll see the error. Unfortunately the error message isn't very accurate in this case.

While the mirror and copy node may be read-only to user connections, it is a read-write database and the operations from the primary need to be applied on a timely basis. Operations not getting applied for hours after they were committed on the primary would be very poor behavior. Requesting a higher isolation level on the mirror or copy node and getting inconsistent results would also be wrong. So locks must be respected, and to avoid applying operations blocking indefinitely, user connections can get rolled back.