| From: | Robert Haas <robertmhaas(at)gmail(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: pgsql: Change ThisTimeLineID from a global variable to a local variable | 
| Date: | 2021-11-07 20:52:41 | 
| Message-ID: | CA+TgmoZcS88WVK8e3ondsjVgqj-qiLgm-tt=q6G3aqEUVSi7Vg@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-committers | 
On Sun, Nov 7, 2021 at 12:23 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yeah.  I've seen some older compilers complain about that code before,
> but now there are over a dozen buildfarm members warning about it.
> It's clearly a false positive, since checkPointLoc does get set in
> the read_backup_label()-failure-return code path.  I think we've
> seen a few other places where likely-to-be-inlined functions have
> to initialize their result variables to prevent compiler warnings,
> so I stuck an initialization step into read_backup_label in hopes
> of silencing it.
That makes sense, and sorry for not noticing this discussion sooner.
But, I'm a bit confused about what's going on here. Why did we start
getting this complaint only now? AFAICS I didn't change anything about
how checkPointLoc is handled. It's an XLogRecPtr, not a TLI, and all
the stuff I changed has to do with TLI handling. I think, anyway.
-- 
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-11-07 21:39:37 | Re: pgsql: Change ThisTimeLineID from a global variable to a local variable | 
| Previous Message | Robert Haas | 2021-11-07 20:36:05 | pgsql: Remove tests added by bd807be6935929bdefe74d1258ca08048f0aafa3. |