From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Dmitry Mityugov <d(dot)mityugov(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings |
Date: | 2025-07-15 23:52:05 |
Message-ID: | 1144304.1752623525@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Tue, Jul 15, 2025 at 7:27 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'd be a bit worried about
>> creating a back-patching mine-field. But maybe these are all
>> in spots we're unlikely to touch?
> That seems like much less of a problem for a purely subtractive change
> such as this.
Not really convinced. Taking a sample at random (from ExecRenameStmt
in alter.c):
return address;
}
default:
elog(ERROR, "unrecognized rename stmt type: %d",
(int) stmt->renameType);
return InvalidObjectAddress; /* keep compiler happy */
}
}
Assume we remove the "return InvalidObjectAddress;" line and later
need to back-patch a change touching this area.
If we were to add/change something in front of the "default:", we're
probably fine because the "default:" and the elog() would be enough
context lines to allow patch(1) to figure out where to put the
addition/change. However, if we wanted to add something after the
switch construct, we'd get an apply failure and have to fix it
manually --- or worse, patch(1) would apply the delta in the
wrong place.
I'm not sure how likely such scenarios are, but it doesn't seem
zero-risk. And if we do hundreds of these, the odds of trouble
will increase.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2025-07-16 00:01:57 | Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings |
Previous Message | Melanie Plageman | 2025-07-15 23:50:48 | Eagerly evict bulkwrite strategy ring |