title: Can read-only rows trigger database deadlocks?
body: <p>Following up on <a href="https://stackoverflow.com/a/16553083/14731">https://stackoverflow.com/a/16553083/14731</a>...</p>
  
  <p>I understand that it is important to maintain a consisting locking order for tables in order to reduce the frequency of deadlocks, and that this affects both <code>UPDATE</code> and <code>SELECT</code> statements [1]. But, <strong>does the same hold true for read-only rows?</strong></p>
  
  <p>If a row is populated once at initialization time and no one modifies it ever again, does it really matter what order we access it?</p>
  
  <p>Given two transactions: T1, T2 and two read-only rows R1, R2</p>
  
  <p>T1 reads R1, then R2
  T2 reads R2, then R1</p>
  
  <p>Can the transactions deadlock, even if I use SERIALIZABLE transaction isolation?</p>
  
  <p>[1] If transaction isolation is <code>REPEATABLE_READ</code>, T1 <code>SELECT</code>s R1, R2 while T2 <code>UPDATE</code>s R2, R1 a deadlock may occur.</p>
  
  <p><strong>CLARIFICATION</strong>: This question is not RDBMS-specific.  I am under the impression that no implementation can deadlock on read-only rows. If you have a counter-example (for a concrete vendor), please post an answer demonstrating as much and I will accept it. Alternatively, post a list of all concrete implementations that you can prove will not deadlock (and the most complete list will get accepted).</p>