On Thu, Feb 17, 2022 at 3:57 PM Robert Haas wrote:
> True. That would be easy enough.
I played around with this a bit, and of course it is easy enough to
add --progress with or without --verbose to a few tests, but when I
reverted 62cb7427d1e491faf8612a82c2e3711a8cd65422 it didn't make any
tests
On Thu, Feb 17, 2022 at 3:51 PM Andres Freund wrote:
> On 2022-02-17 15:22:08 -0500, Robert Haas wrote:
> > OK, sounds good, thanks. I couldn't (and still can't) think of a good
> > way of testing the progress-reporting code either. I mean I guess if
> > you could convince pg_basebackup not to tru
On 2022-02-17 15:22:08 -0500, Robert Haas wrote:
> OK, sounds good, thanks. I couldn't (and still can't) think of a good
> way of testing the progress-reporting code either. I mean I guess if
> you could convince pg_basebackup not to truncate the filenames, maybe
> by convincing it that your termin
On Thu, Feb 17, 2022 at 2:36 PM Tom Lane wrote:
> Yeah, I came to the same conclusion while out doing some errands.
> There's no very convincing reason to believe that what's passed to
> progress_update_filename has got adequate lifespan either, or that
> that would remain true even if it's true t
Robert Haas writes:
> If not, I think that your quick-and-dirty fix is about right, except
> that we probably need to do it every place where we set
> progress_filename, and we should arrange to free the memory later.
> With -Ft, you won't have enough archives to matter, but with -Fp, you
> might
On Thu, Feb 17, 2022 at 12:08 PM Tom Lane wrote:
> I wrote:
> > Justin Pryzby writes:
> >> pg_basebackup.c:1261:35: warning: storing the address of local variable
> >> archive_filename in progress_filename [-Wdangling-pointer=]
> >> => new in 23a1c6578 - looks like a real error
>
> > I saw that
I wrote:
> Justin Pryzby writes:
>> pg_basebackup.c:1261:35: warning: storing the address of local variable
>> archive_filename in progress_filename [-Wdangling-pointer=]
>> => new in 23a1c6578 - looks like a real error
> I saw that one a few days ago but didn't get around to looking
> more clos
On 2/12/22 16:13, Justin Pryzby wrote:
> Is there any check for warnings from new code, other than those buildfarm
> members with -Werror ?
I had forgotten about this :-) but a few years ago I provided a
check_warnings setting (and a --check-warnings command line parameter).
It's processed if s
On Mon, Feb 14, 2022 at 6:10 AM Tom Lane wrote:
> Another thing I've been ignoring on the grounds that I-don't-feel-
> like-fixing-this is that the Solaris and OpenIndiana machines whine
> about every single reference from loadable modules to the core code,
> eg this from haddock while building co
On 2/13/22 13:59, Tom Lane wrote:
> So we're faced with a dilemma: we can't rename either instance without
> breaking something. The only way to get rid of the warnings seems to be
> to decide that the copy in xml2 has outlived its usefulness and remove
> it. I don't think that's a hard argumen
On 2/12/22 16:42, Tom Lane wrote:
>> I'm of the impression that some people have sql access to BF logs.
> Yeah. I'm not sure exactly what the access policy is for that machine;
> I know we'll give out logins to committers, but not whether there's
> any precedent for non-committers.
Yeah, I don
I wrote:
> This conversation motivated me to take a fresh pass over said filtering
> script, and one thing I notice that it's been ignoring is these complaints
> from all the AIX animals:
> ld: 0711-224 WARNING: Duplicate symbol: .xml_is_well_formed
> ld: 0711-224 WARNING: Duplicate symbol: xml_is
I wrote:
> Justin Pryzby writes:
>> Is there any check for warnings from new code, other than those buildfarm
>> members with -Werror ?
> I periodically grep the buildfarm logs for interesting warnings.
> There are a lot of uninteresting ones :-(, so I'm not sure how
> automatable that'd be. I d
Hi,
On 2022-02-12 16:42:03 -0500, Tom Lane wrote:
> Another new one that maybe should be silenced is
>
> /mnt/resource/bf/build/skink-master/HEAD/pgsql.build/../pgsql/src/backend/access/heap/vacuumlazy.c:1129:41:
> warning: 'freespace' may be used uninitialized in this function
> [-Wmaybe-uninit
Justin Pryzby writes:
> Is there any check for warnings from new code, other than those buildfarm
> members with -Werror ?
I periodically grep the buildfarm logs for interesting warnings.
There are a lot of uninteresting ones :-(, so I'm not sure how
automatable that'd be. I do use a prefilterin
Is there any check for warnings from new code, other than those buildfarm
members with -Werror ?
It'd be better to avoid warnings, allowing members to use -Werror, rather than
to allow/ignore warnings, which preclude that possibility. A circular problem.
I checked for warnings on master during "
16 matches
Mail list logo
