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
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 |