Re: [HACKERS] 'Waiting on lock'

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-patches" <pgsql-patches(at)postgresql(dot)org>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Subject: Re: [HACKERS] 'Waiting on lock'
Date: 2007-06-20 09:14:02
Message-ID: 87ps3rf0o5.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2007-06-20 13:40:57 [gpoo@ubiobio.cl: Re: [HACKERS] EXPLAIN omits schema?]
Previous Message Alexey Klyukin 2007-06-20 07:50:00 bitmapscan changes patch review