Re: [HACKERS] 'Waiting on lock' - Mailing list pgsql-patches

From Gregory Stark
Subject Re: [HACKERS] 'Waiting on lock'
Date
Msg-id 87ps3rf0o5.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: [HACKERS] 'Waiting on lock'  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] 'Waiting on lock'  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Alexey Klyukin
Date:
Subject: bitmapscan changes patch review
Next
From: Alvaro Herrera
Date:
Subject: [gpoo@ubiobio.cl: Re: [HACKERS] EXPLAIN omits schema?]