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'  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Alexey Klyukin
Дата:
Сообщение: bitmapscan changes patch review
Следующее
От: Alvaro Herrera
Дата:
Сообщение: [gpoo@ubiobio.cl: Re: [HACKERS] EXPLAIN omits schema?]