| 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: | Whole Thread | Raw Message | 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 |