locking...
От | Vadim Mikheev |
---|---|
Тема | locking... |
Дата | |
Msg-id | 372AB9FA.47E81111@krs.ru обсуждение исходный текст |
Список | pgsql-hackers |
session-1: vac=> begin; BEGIN vac=> lock table t in row share mode; LOCK TABLE vac=> session-2: vac=> begin; BEGIN vac=> lock table t in exclusive mode; -- waiting session-3: vac=> begin; BEGIN vac=> lock table t in row share mode; LOCK TABLE vac=> ??? First, I agree to give some transaction extra priority while locking table A but _only_ if transaction already has any kind of lock on _this_ table. I object to do this if transaction has only locks on _other_ tables - this will result in starving. Second, session-3 didn't hold any kind of locks but MyProc->lockQueue wasn't empty! Why? And last: try to press Ctrl-D in session-3 and you'll get NOTICE: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. in session-2. Core made for session-3: #5 0x8114fea in ExceptionalCondition ( conditionName=0x814f9d8 "!((((unsigned long)queue) > ShmemBase))", exceptionP=0x816490c,detail=0x0, fileName=0x814f9cd "shmqueue.c", lineNumber=248) at assert.c:74 #6 0x80defc3 in SHMQueueEmpty (queue=0x48) at shmqueue.c:248 #7 0x80e2be4 in LockResolveConflicts (lockmethod=1, lock=0x30252d68, lockmode=6, xid=34309, xidentP=0x0) at lock.c:832 #8 0x80e4690 in ProcLockWakeup (queue=0x30252d7c, lockmethod=1, lock=0x30252d68) at proc.c:683 #9 0x80e3ade in LockReleaseAll (lockmethod=1, lockQueue=0x30252ce8) at lock.c:1456 #10 0x80e438d in ProcKill (exitStatus=0, pid=24636) at proc.c:410 #11 0x80dd92c in shmem_exit (code=0) at ipc.c:193 #12 0x80dd861 in proc_exit (code=0) at ipc.c:139 #13 0x80e8a8c in PostgresMain (argc=11, argv=0xefbfccfc, real_argc=6, real_argv=0xefbfd774) at postgres.c:1672 Vadim
В списке pgsql-hackers по дате отправления: