Re: Compilation error with buildtype = release

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Compilation error with buildtype = release
Date: 2025-07-30 04:32:24
Message-ID: CAExHW5vNj_PO1AyKhQQips9oWK8X4FDqi9Zs8YUcvviVes-TGw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 29, 2025 at 6:36 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> writes:
> > I am seeing following error only with buildtype = release
>
> Interesting. I noticed skink showing the same thing as a warning,
> but no other BF animals have shown it (yet anyway).
>
> > Looking at the function, reltuples is indeed initialized in all the
> > cases. All the relevant lines of the function are at least 3 years
> > old, but I have started seeing this error only after
> > 80aa9848befc13c188d2775a859deaf172fdd3a2.
>
> Yeah. The variable is clearly initialized in all cases where it's
> used, but a compiler doing sloppy flow analysis might complain.
> I suspect the relevance of 80aa9848b is that when there was a PG_TRY
> in the function, these compilers backed off and didn't try to do flow
> analysis at all.
>
> > If I make the change as per attached patch, it compiles without an
> > error. I don't claim that the patch is the right thing to do, but it
> > might provide a hint.
>
> Usually my answer to this sort of thing is to provide an initializer
> for the variable. Will fix.

Thanks.

--
Best Wishes,
Ashutosh Bapat

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-07-30 04:44:54 Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row
Previous Message jian he 2025-07-30 03:21:55 Re: speedup COPY TO for partitioned table.