Re: Is element access after HASH_REMOVE ever OK?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is element access after HASH_REMOVE ever OK?
Date: 2021-05-11 00:15:41
Message-ID: 805441.1620692141@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> ... Can we get rid of the unsafe
> access easily?

Oh, shoulda read your second patch first. Looking at that,
I fear it might not be quite that simple, because the
comment on CheckAndSetLockHeld says very clearly

* It is callers responsibility that this function is called after
* acquiring/releasing the relation extension/page lock.

so your proposed patch violates that specification.

I'm inclined to think that this API spec is very poorly thought out
and should be changed --- why is it that the flags should change
*after* the lock change in both directions? But we'd have to take
a look at the usage of these flags to understand what's going on
exactly.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2021-05-11 00:16:44 Re: seawasp failing, maybe in glibc allocator
Previous Message Tom Lane 2021-05-11 00:06:10 Re: Is element access after HASH_REMOVE ever OK?