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)
>> ==00:00:00:32.
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 reaso
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 d
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 t
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 p
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 RT_AL
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 makin
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 valgri
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 haven't
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
15 matches
Mail list logo
