Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ?

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Peter Smith <smithpb2250(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:20:37
Message-ID: CA+hUKGLY=p4D=iW1TRVTK=cY3AOhFV3B--HMZHbjL6GypoT8+Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-03-21 22:27:40 Re: 64-bit XIDs in deleted nbtree pages
Previous Message Stephen Frost 2021-03-21 22:16:06 Re: shared memory stats: high level design decisions: consistency, dropping