title: Postgres: Where does this deadlock come from?
body: <p>pg_log:</p>
  
  <pre><code>2016-01-20 23:00:31 UTC ERROR:  deadlock detected
  2016-01-20 23:00:31 UTC DETAIL:  
      Process 2696 waits for RowShareLock on relation 1849109 of database 1847373; blocked by process 2919.
      Process 2919 waits for AccessExclusiveLock on relation 1848698 of database 1847373; blocked by process 2696.
      Process 2696:
                  INSERT INTO install_session (
                      [..]
                  ) VALUES (
                      [..]
                  )
  
      Process 2919: DROP TABLE IF EXISTS install_view_2015_11_20
  2016-01-20 23:00:31 UTC HINT:  See server log for query details.
  </code></pre>
  
  <p>Querying the mentioned relations gives me:</p>
  
  <pre><code>select * from pg_class where oid = 1849109;
  &gt; install
  select * from pg_class where oid = 1848698; 
  &gt; app
  </code></pre>
  
  <p>Questions:</p>
  
  <ol>
  <li>Why does the deadlock happen at all? The <code>INSERT</code> and the <code>DROP</code> are aiming at two different tables.</li>
  <li>What do the other two relations/tables (install, app) have to do with it?</li>
  </ol>
  
  <p>Postgres 9.3</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>I indeed do have <code>triggers</code>:</p>
  
  <pre><code>CREATE OR REPLACE FUNCTION insert_install_session()
          RETURNS TRIGGER AS $$
          BEGIN
              EXECUTE 'INSERT INTO install_session_'
                  || to_char(NEW.created, 'YYYY_MM_DD') || 
                  ' SELECT ($1).*'
              USING NEW;
              RETURN NULL;
          END;
          $$
          LANGUAGE PLPGSQL
  
    CREATE TRIGGER trigger_insert_install_session
          BEFORE INSERT ON install_session
          FOR EACH ROW EXECUTE PROCEDURE insert_install_session()
  </code></pre>
  
  <p>and <code>foreign keys</code> from all partitions (install_session_XXXX_XX_XX and install_view_XXXX_XX_XX in this case) referencing the tables <code>app</code> and <code>install</code>.</p>
  
  <p>That makes things a bit more clear, but I still don't understand why the <code>DROP</code> command needs to lock any tables other than the table that should be dropped. </p>