MySQL SELECT blocking an INSERT? Is it possible for a  SELECT query to block INSERT / ALTER queries?

I have the following (taken from ENGINE INNODB STATUS) on my slave database:

---TRANSACTION 26DA7060, not started
mysql tables in use 5, locked 12
MySQL thread id 516232, OS thread handle 0x7fcf8304a700, query id 350388626 event_scheduler Waiting for table metadata lock
ALTER TABLE xxxxxxxxxxxx REORGANIZE PARTITION . . . .

---TRANSACTION 26DA705F, ACTIVE 201692 sec
5 lock struct(s), heap size 1248, 3 row lock(s), undo log entries 1
MySQL thread id 2, OS thread handle 0x7fc99aa91700, query id 350388642 Waiting for table metadata lock
INSERT INTO xxxxxxxxxxxx VALUES (. . . . . . . . . . . . .)

---TRANSACTION 2499F3C3, ACTIVE 1031443 sec fetching rows
mysql tables in use 11, locked 0
MySQL thread id 338078, OS thread handle 0x7fcf830dd700, query id 260018270 127.0.0.1 xxxxxxxxxxx Sending data
SELECT . . . .
Trx read view will not see trx with id &gt;= 2499F3C4, sees &lt; 2486B035

---TRANSACTION 2499EB0F, ACTIVE 1031500 sec fetching rows
mysql tables in use 11, locked 0
MySQL thread id 338037, OS thread handle 0x7fcf8307b700, query id 260008885 127.0.0.1 xxxxxxxxxxx Sending data
SELECT . . . .
Trx read view will not see trx with id &gt;= 2499EB10, sees &lt; 2486B035

---TRANSACTION 2486B035, ACTIVE 1091724 sec fetching rows
mysql tables in use 11, locked 0
MySQL thread id 330522, OS thread handle 0x7fcf8313f700, query id 255888600 127.0.0.1 xxxxxxxxxxx Sending data
SELECT . . . .
Tr  Trx read view will not see trx with id &gt;= 2486B036, sees &lt; 2486B036


They all use the same table. 
The SELECTs are identical queries, and have a couple of joins to little used tables.
The INSERT is a simple INSERT with no joins.
THE ALTER is a simple ALTER TABLE REORGANIZE PARTITION. 

The top one (ALTER TABLE) should have started about 48 hours earlier.
The INSERT about two minutes before the ALTER.

I can understand why the INSERT would block the ALTER, but can't see why the SELECT would block the INSERT.
And if it really had been running that long, it should have blocked previous INSERTs (we INSERT about 250 times a minute on average).

So I'm just trying to figure out what had happenned.
The output is only showing the current query in a transaction.  What else is in the BEGIN...COMMIT?  Or are you running autocommit=0?  Or =1?

SELECT grabs shared locks on the rows it is looking at, for the duration of the transaction.

INSERT grabs exclusive lock(s).  It sounds like the SELECT already has a lock that the INSERT desires.

Perhaps the SELECT involves a table scan?

Note also that it says table metadata lock.  This is something 'bigger' than a "row lock".

If you have an 11-table JOIN that it taking 12 days, I suspect you are missing an index.  Or perhaps missing an ON clause, thereby turning a INNER JOIN into a very costly CROSS JOIN.  Please provide the EXPLAIN, the SELECT and SHOW CREATE TABLE if you would like us to dig deeper into this possibility.