Decibel! escribió:
> Yeah, if you look at the code, locks are defined as numbers and I
> believe there's a very simple patter of what conflicts; a higher lock
> number conflicts with all those that are lower. So, it might be a lot
> cleaner to have a function that defines numbers for all the
On Jun 19, 2008, at 8:07 AM, David Fetter wrote:
On Wed, Jun 18, 2008 at 05:39:59PM -0700, Jeff Davis wrote:
I was trying to create a more "at-a-glance" view of the pg_locks
table.
I included the SQL I came up with (after talking to Merlin) at the
bottom of this message.
The idea is to show a
On Thu, 2008-06-19 at 06:07 -0700, David Fetter wrote:
> I'm not exactly sure, but it appears to match, at first blush, what's
> in src/backend/storage/lmgr/lock.c:
> static const LOCKMASK LockConflicts[] = {
>
I was more interested in the view itself. Is the view an accurate way to
interpret
On Thu, Jun 19, 2008 at 9:07 AM, David Fetter <[EMAIL PROTECTED]>
> There's stuff in the aforementioned lock.c, but I don't see anything
> visible to SQL.
Maybe it should be...via C. if you use an enum for lockmode, you
don't need pl/pgsql at all...
merlin
--
Sent via pgsql-general mailing li
On Wed, Jun 18, 2008 at 05:39:59PM -0700, Jeff Davis wrote:
> I was trying to create a more "at-a-glance" view of the pg_locks table.
> I included the SQL I came up with (after talking to Merlin) at the
> bottom of this message.
>
> The idea is to show any queries that are waiting on a lock, and t
I was trying to create a more "at-a-glance" view of the pg_locks table.
I included the SQL I came up with (after talking to Merlin) at the
bottom of this message.
The idea is to show any queries that are waiting on a lock, and the
query that currently holds the lock on which those queries are wait
