From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ? |
Date: | 2021-03-21 22:44:15 |
Message-ID: | CAHut+PucpZNWYrhSbJij0w4CazrEYDPm_RFUA4NoFrkUzP8wyA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 22, 2021 at 9:21 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Mon, Mar 22, 2021 at 10:50 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> > The real problem isn't the Assert. It's all those other usages of ent
> > disobeying the API rule: "(NB: in the case of the REMOVE action, the
> > result is a dangling pointer that shouldn't be dereferenced!)"
>
> I suppose the HASH_REMOVE case could clobber the object with 0x7f if
> CLOBBER_FREED_MEMORY is defined (typically assertion builds), or
> alternatively return some other non-NULL but poisoned pointer, so that
> problems of this ilk blow up in early testing.
+1, but not sure if the poisoned ptr alternative can work because some
code (e.g see RemoveTargetIfNoLongerUsed function) is asserting the
return ptr actual value, not just its NULL-ness.
------
Kind Regards,
Peter Smith.
Fujitsu Australia.
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-03-21 22:56:15 | Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ? |
Previous Message | Andres Freund | 2021-03-21 22:34:45 | Re: shared memory stats: high level design decisions: consistency, dropping |