From 9b92e76f7b6dcdc2de6fae53a1c069297ba454fc Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 13 Feb 2016 15:42:31 -0500 Subject: [PATCH] Make GetLockStatusData's header comment resemble reality. The API spec for this function was changed completely (and for the better) by commit 3cba8999b343648c4c528432ab3d51400194e93b, but it didn't bother with anything as mundane as updating the comments. --- src/backend/storage/lmgr/lock.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c index e3e9599fc9..fef59a280a 100644 --- a/src/backend/storage/lmgr/lock.c +++ b/src/backend/storage/lmgr/lock.c @@ -3371,10 +3371,11 @@ LockShmemSize(void) * GetLockStatusData - Return a summary of the lock manager's internal * status, for use in a user-level reporting function. * - * The return data consists of an array of PROCLOCK objects, with the - * associated PGPROC and LOCK objects for each. Note that multiple - * copies of the same PGPROC and/or LOCK objects are likely to appear. - * It is the caller's responsibility to match up duplicates if wanted. + * The return data consists of an array of LockInstanceData objects, + * which are a lightly abstracted version of the PROCLOCK data structures, + * i.e. there is one entry for each unique lock and interested PGPROC. + * It is the caller's responsibility to match up related items (such as + * references to the same lockable object or PGPROC) if wanted. * * The design goal is to hold the LWLocks for as short a time as possible; * thus, this function simply makes a copy of the necessary data and releases -- 2.40.0