John Naylor writes:
> Pushed. I'll clear the open item once all buildfarm members have reported in.
Just to confirm, my raspberry pi 4 got through "make
installcheck-parallel" under valgrind after this commit.
regards, tom lane
On Thu, Jun 20, 2024 at 2:58 PM John Naylor wrote:
> the struct. If that's agreeable I'll commit it that way tomorrow
> unless someone beats me to it.
Pushed. I'll clear the open item once all buildfarm members have reported in.
Ranier Vilela writes:
> Em qua., 19 de jun. de 2024 às 20:52, Tom Lane escreveu:
>> Hah: it's the second case. If I patch radixtree.h as attached,
>> then x86_64 valgrind complains about
>> ==00:00:00:32.759 247596== Conditional jump or move depends on
>> uninitialised value(s)
>>
On Thu, Jun 20, 2024 at 4:58 PM John Naylor wrote:
>
> On Thu, Jun 20, 2024 at 8:12 AM Masahiko Sawada wrote:
>
> > On Thu, Jun 20, 2024 at 7:54 AM Tom Lane wrote:
> > >
> > > I don't know if there's any reason why the current order
> > > is preferable.)
> >
> > IIUC there is no particular
Em qua., 19 de jun. de 2024 às 20:52, Tom Lane escreveu:
> I wrote:
> > I hypothesize that the reason we're not seeing equivalent failures
> > on x86_64 is one of
>
> > 1. x86_64 valgrind is stupider than aarch64, and fails to track that
> > the contents of the SIMD registers are only partially
John Naylor writes:
> On Thu, Jun 20, 2024 at 8:12 AM Masahiko Sawada wrote:
>> IIUC there is no particular reason for the current order in RT_NODE_48.
> Yeah. I found that simply swapping them enables clang to avoid
> double-initialization, but gcc still can't figure it out and must be
> told
On Thu, Jun 20, 2024 at 8:12 AM Masahiko Sawada wrote:
> On Thu, Jun 20, 2024 at 7:54 AM Tom Lane wrote:
> >
> I agree with radixtree-fix-proposed.patch. Even if we zero more fields
> in the node it would not add noticeable overheads.
+1 in general, although I'm slightly concerned about this
On Thu, Jun 20, 2024 at 10:11:37AM +0900, Masahiko Sawada wrote:
> I agree with radixtree-fix-proposed.patch. Even if we zero more fields
> in the node it would not add noticeable overheads.
This needs to be tracked as an open item, so I have added one now.
--
Michael
signature.asc
Description:
Hi,
On Thu, Jun 20, 2024 at 7:54 AM Tom Lane wrote:
>
> I wrote:
> > I've reproduced what looks like about the same thing on
> > my Pi 4 using Fedora 38: just run "make installcheck-parallel"
> > under valgrind, and kaboom. Definitely needs investigation.
>
> The problem appears to be that
I wrote:
> I hypothesize that the reason we're not seeing equivalent failures
> on x86_64 is one of
> 1. x86_64 valgrind is stupider than aarch64, and fails to track that
> the contents of the SIMD registers are only partially defined.
> 2. x86_64 valgrind is smarter than aarch64, and is able to
I wrote:
> I hypothesize that the reason we're not seeing equivalent failures
> on x86_64 is one of
> 1. x86_64 valgrind is stupider than aarch64, and fails to track that
> the contents of the SIMD registers are only partially defined.
> 2. x86_64 valgrind is smarter than aarch64, and is able to
I wrote:
> I've reproduced what looks like about the same thing on
> my Pi 4 using Fedora 38: just run "make installcheck-parallel"
> under valgrind, and kaboom. Definitely needs investigation.
The problem appears to be that RT_ALLOC_NODE doesn't bother to
initialize the chunks[] array when
Tomas Vondra writes:
> On 6/19/24 17:11, Tom Lane wrote:
>> What's the test scenario that triggers this?
> I haven't investigated that yet, I just ran "make check".
I've reproduced what looks like about the same thing on
my Pi 4 using Fedora 38: just run "make installcheck-parallel"
under
On 6/19/24 17:11, Tom Lane wrote:
> Tomas Vondra writes:
>> I tried running master under valgrind on 64-bit ARM (rpi5 running debian
>> 12.5), and I got some suspicous reports, all related to the radixtree
>> code used by tidstore.
>
> What's the test scenario that triggers this?
>
I
Tomas Vondra writes:
> I tried running master under valgrind on 64-bit ARM (rpi5 running debian
> 12.5), and I got some suspicous reports, all related to the radixtree
> code used by tidstore.
What's the test scenario that triggers this?
regards, tom lane
Hi,
I tried running master under valgrind on 64-bit ARM (rpi5 running debian
12.5), and I got some suspicous reports, all related to the radixtree
code used by tidstore. I'm used to valgrind on arm sometimes reporting
harmless issues, but this seems like it might be an actual issue.
I'm
16 matches
Mail list logo
