Skip to content

Commit c9de1b8

Browse files
committed
Warn if LOCKTAG_TUPLE is held at commit, under debug_assertions.
The current use always releases this locktag. A planned use will continue that intent. It will involve more areas of code, making unlock omissions easier. Warn under debug_assertions, like we do for various resource leaks. Back-patch to v12 (all supported versions), the plan for the commit of the new use. Reviewed by Heikki Linnakangas. Discussion: https://postgr.es/m/20240512232923.aa.nmisch@google.com
1 parent 988ddbe commit c9de1b8

File tree

1 file changed

+10
-0
lines changed
  • src/backend/storage/lmgr

1 file changed

+10
-0
lines changed

src/backend/storage/lmgr/lock.c

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2277,6 +2277,16 @@ LockReleaseAll(LOCKMETHODID lockmethodid, bool allLocks)
22772277
locallock->numLockOwners = 0;
22782278
}
22792279

2280+
#ifdef USE_ASSERT_CHECKING
2281+
2282+
/*
2283+
* Tuple locks are currently held only for short durations within a
2284+
* transaction. Check that we didn't forget to release one.
2285+
*/
2286+
if (LOCALLOCK_LOCKTAG(*locallock) == LOCKTAG_TUPLE && !allLocks)
2287+
elog(WARNING, "tuple lock held at commit");
2288+
#endif
2289+
22802290
/*
22812291
* If the lock or proclock pointers are NULL, this lock was taken via
22822292
* the relation fast-path (and is not known to have been transferred).

0 commit comments

Comments
 (0)