On Thu, Dec 21, 2023 at 10:00 AM Alexander Lakhin <exclusion@gmail.com> wrote:
> Please look at the attached patch; it corrects all 29 items ("recods"
> fixed in two places), but maybe you find some substitutions wrong...
Thanks, committed with a few additions.
> I've also observed that those commits introduced new warnings:
> $ CC=gcc-12 CPPFLAGS="-Wtype-limits" ./configure -q && make -s -j8
> reconstruct.c: In function ‘read_bytes’:
> reconstruct.c:511:24: warning: comparison of unsigned expression in ‘< 0’ is always false [-Wtype-limits]
> 511 | if (rb < 0)
> | ^
> reconstruct.c: In function ‘write_reconstructed_file’:
> reconstruct.c:650:40: warning: comparison of unsigned expression in ‘< 0’ is always false [-Wtype-limits]
> 650 | if (rb < 0)
> | ^
> reconstruct.c:662:32: warning: comparison of unsigned expression in ‘< 0’ is always false [-Wtype-limits]
> 662 | if (wb < 0)
Oops. I think the variables should be type int. See attached.
> There are also two deadcode.DeadStores complaints from clang. First one is
> about:
> /*
> * Align the wait time to prevent drift. This doesn't really matter,
> * but we'd like the warnings about how long we've been waiting to say
> * 10 seconds, 20 seconds, 30 seconds, 40 seconds ... without ever
> * drifting to something that is not a multiple of ten.
> */
> timeout_in_ms -=
> TimestampDifferenceMilliseconds(current_time, initial_time) %
> timeout_in_ms;
> It looks like this timeout is really not used.
Oops. It should be. See attached.
> And the minor one (similar to many existing, maybe doesn't deserve fixing):
> walsummarizer.c:808:5: warning: Value stored to 'summary_end_lsn' is never read [deadcode.DeadStores]
> summary_end_lsn = private_data->read_upto;
> ^ ~~~~~~~~~~~~~~~~~~~~~~~
It kind of surprises me that this is dead, but it seems best to keep
it there to be on the safe side, in case some change to the logic
renders it not dead in the future.
> >> Also, a comment above MaybeRemoveOldWalSummaries() basically repeats a
> >> comment above redo_pointer_at_last_summary_removal declaration, but
> >> perhaps it should say about removing summaries instead?
> > Wow, yeah. Thanks, will fix.
>
> Thank you for paying attention to it!
I'll fix this next.
--
Robert Haas
EDB: http://www.enterprisedb.com
