On 16.07.25 01:35, Peter Geoghegan wrote:
On Sat, Jul 12, 2025 at 1:55 PM Andres Freund wrote:
I had played with using pg_assume here too, but I couldn't really convince
myself that it's a good idea...
In the past, it was often necessary to work around MSVC's inability to
see that a block con
On Tue, Jul 15, 2025 at 7:52 PM Tom Lane wrote:
> 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.
I agree that it's not zero-risk -- hardly anything ever is. Still
seems worth considering.
--
Pete
Peter Geoghegan writes:
> On Tue, Jul 15, 2025 at 7:27 PM Tom Lane 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.
On Tue, Jul 15, 2025 at 7:27 PM Tom Lane wrote:
> There are a lot of them, for sure.
It's *very* common for switch statements to have a "can't happen"
elog(ERROR) as their default block. Many of these default blocks also
initialize related variables to placate the compiler.
> I'd be a bit worrie
Peter Geoghegan writes:
> It would be nice to eliminate all existing "keep compiler quiet"
> variable initializations that follow an elog/ereport with elevel >=
> ERROR. My guess is that we have several hundred.
There are a lot of them, for sure. I'd be a bit worried about
creating a back-patchi
On Tue, Jul 15, 2025 at 6:58 PM Tom Lane wrote:
> Good question. It's not very clear what set of compiler versions
> people are still using, but maybe it'd be okay to stop worrying
> about suppressing such warnings.
It would be nice to eliminate all existing "keep compiler quiet"
variable initia
Peter Geoghegan writes:
> In the past, it was often necessary to work around MSVC's inability to
> see that a block containing elog(ERROR) doesn't actually need to
> initialize variables that'll never actually be used in code that comes
> after that block. We still have many "keep compiler quiet"
On Sat, Jul 12, 2025 at 1:55 PM Andres Freund wrote:
> I had played with using pg_assume here too, but I couldn't really convince
> myself that it's a good idea...
In the past, it was often necessary to work around MSVC's inability to
see that a block containing elog(ERROR) doesn't actually need
After further study I've understood what was bothering me about
the logic in compareJsonbContainers (lines 280ff). Because
JsonbIteratorNext doesn't presently guarantee to set val->type
when returning WJB_DONE, the stanza appears to be at risk of
undefined behavior should one iterator return that
Andres Freund writes:
> On 2025-07-12 13:42:54 -0400, Tom Lane wrote:
>> I don't care for this patch: replacing an Assert with pg_assume just
>> seems like a very bad idea.
> That shouldn't be a problem - pg_assume() is defined to be an Assert() in
> USE_ASSERT_CHECKING builds.
Ah, my bad. But
Hi,
On 2025-07-12 13:42:54 -0400, Tom Lane wrote:
> Dmitry Mityugov writes:
> > When compiled with Assert() macro disabled, GCC 15 produces warnings
> > about possibly uninitialized variables in
> > src/backend/utils/adt/jsonb_util.c module. This problem was discussed in
> > detail in this thr
Dmitry Mityugov writes:
> When compiled with Assert() macro disabled, GCC 15 produces warnings
> about possibly uninitialized variables in
> src/backend/utils/adt/jsonb_util.c module. This problem was discussed in
> detail in this thread, in April 2025:
> https://www.postgresql.org/message-id/
Op 7/10/25 om 22:00 schreef Dmitry Mityugov:
When compiled with Assert() macro disabled, GCC 15 produces warnings
about possibly uninitialized variables in
src/backend/utils/adt/jsonb_util.c module. This problem was discussed in
detail in this thread, in April 2025:
https://www.postgresql.org/
When compiled with Assert() macro disabled, GCC 15 produces warnings
about possibly uninitialized variables in
src/backend/utils/adt/jsonb_util.c module. This problem was discussed in
detail in this thread, in April 2025:
https://www.postgresql.org/message-id/988bf1bc-3f1f-99f3-bf98-222f1cd9d..
14 matches
Mail list logo
