Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, David Zhang <david(dot)zhang(at)highgo(dot)ca>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
Date: 2022-08-24 19:00:10
Message-ID: 1141325.1661367610@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 24.08.22 16:30, Alvaro Herrera wrote:
>> If you do this, you're creating a potential backpatching hazard. This
>> is OK if we get something in return, so a question to ask is whether
>> there is any benefit in doing it.

> I don't follow how this is a backpatching hazard.

Call me a trogdolyte, but I don't follow how it's an improvement.
It looks to me like an entirely random change that doesn't get rid
of assumptions about what the bits are, it just replaces one set of
assumptions with a different set. Moreover, the new set of assumptions
may include "there are no padding bits in here", which is mighty fragile
and hard to verify. So I frankly do not find this a stylistic improvement.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-08-24 19:19:35 Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
Previous Message Peter Eisentraut 2022-08-24 18:50:56 Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)