Re: [HACKERS] 'Waiting on lock'
От | Gregory Stark |
---|---|
Тема | Re: [HACKERS] 'Waiting on lock' |
Дата | |
Msg-id | 87ps3rf0o5.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] 'Waiting on lock' (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] 'Waiting on lock'
|
Список | pgsql-patches |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Applied with some further revisions to improve the usefulness of the log > messages. There's now one issued when the deadlock timeout elapses, and > another when the lock is finally obtained: > > LOG: process 14945 still waiting for AccessExclusiveLock on relation 86076 of database 86042 after 1003.354 ms > ... > LOG: process 14945 acquired AccessExclusiveLock on relation 86076 of database 86042 after 5918.002 ms Is it possible for unlocking the semaphore to wake another process other than our own? In which case checking log_lock_waits before signalling the semaphore arguably locks us into having log_lock_waits be PGC_POSTMASTER. Currently it's PGC_SIGHUP which is odd since it could have been USERSET in the old regime. Also, I did just think of a reason why maybe having the times in the messages could be annoying: it makes it hard to write regression tests. I suppose having the pids already interferes with regression tests though. Maybe we should do something like optionally postprocess .out files with some sed script like s/[0-9]+/###/ before running diff. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: