From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Is element access after HASH_REMOVE ever OK? |
Date: | 2021-05-10 23:37:04 |
Message-ID: | CA+hUKGJ-ysnJFQJ5A67Gpj4g2Hu7W965qePF6+ReWMvn5j+Z6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
After hearing from a couple of directions about systems spending too
much time scanning the local lock hash table, I wrote the trivial
patch to put them in a linked list, before learning that people have
considered that before, so I should probably go and read some history
on that and find out why it hasn't been done...
However, I noticed in passing that RemoveLocalLock() accesses
*locallock after removing it from the hash table (in assertion builds
only). So one question I have is whether it's actually a programming
rule that you can't do that (at most you can compare the pointer
against NULL), or whether it's supposed to be
safe-if-you-know-what-you're-doing, as the existing comments hints.
Here also is a patch that does wipe_mem on removed elements, as
threatened last time this topic came up[1], which reveals the problem.
I'm also not exactly sure why it's only a WARNING if your local lock
table is out of sync, but perhaps that's in the archives too.
Attachment | Content-Type | Size |
---|---|---|
0001-Clobber-memory-released-by-HASH_REMOVE.patch | text/x-patch | 1.2 KB |
0002-Don-t-access-a-local-locks-after-freeing-them.patch | text/x-patch | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-05-11 00:06:10 | Re: Is element access after HASH_REMOVE ever OK? |
Previous Message | Andres Freund | 2021-05-10 23:17:25 | Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS |