Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data - Mailing list pgsql-bugs

From Noah Misch
Subject Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Date
Msg-id 20211110035341.GC968057@rfd.leadboat.com
Whole thread Raw
In response to Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-bugs
On Wed, Nov 10, 2021 at 10:55:13AM +1300, Thomas Munro wrote:
> On Wed, Nov 10, 2021 at 3:40 AM Noah Misch <noah@leadboat.com> wrote:
> > $ diff -U0 <(cut -b47- disasm/70bef49/equalTupleDescs) <(cut -b47- disasm/166f943/equalTupleDescs)
> > --- /dev/fd/63  2021-11-09 06:11:20.927444437 -0800
> > +++ /dev/fd/62  2021-11-09 06:11:20.926444428 -0800
> > @@ -100 +100 @@
> > -      br.call.sptk.many rp=0x40000000003cdc20
> > +      br.call.sptk.many rp=0x40000000003cde20
> > @@ -658 +658 @@
> > -      br.call.sptk.many rp=0x40000000003cdc20
> > +      br.call.sptk.many rp=0x40000000003cde20
> > @@ -817 +817 @@
> > -             br.call.sptk.many rp=0x3fffffffff3fdc30
> > +             br.call.sptk.many rp=0x4000000000400c30
> > @@ -949 +949 @@
> > -             br.call.sptk.many rp=0x40000000003cdc20
> > +             br.call.sptk.many rp=0x40000000003cde20
> > @@ -970 +970 @@
> > -             br.call.sptk.many rp=0x40000000003cdc20
> > +             br.call.sptk.many rp=0x40000000003cde20
> >
> > Since "git diff 70bef49 166f943" contains nothing that correlates with such a
> > change, I'm concluding that this is a bug in gharial's toolchain.
> 
> Excellent detective work.

Thanks.

> > It looks like gharial's automatic buildfarm runs have been paused for nine
> > days.  Feel free to unpause it.  Also, I recommend using the buildfarm client
> > setnotes.pl to add a note like 'Rare signal 11 from toolchain bug'.  Months or
> > years pass between these events.  Here are all gharial "signal 11" failures,
> > likely some of which have other causes:
> 
> Yeah I spent time investigating some of these at the time and I know
> others did too.
> 
> IMHO we should hunt down dead toolchains and gently see if we can get
> them updated.   There is no point in testing PostgreSQL on every
> commit on a compiler someone built from a tarball many years ago and
> never updated with bug fixes.

+1 for "gently see if".  It's good that we have a few old-gcc animals, but
having versions of intermediate age is less important.  Some owners will
decline, and that's okay.



pgsql-bugs by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum
Next
From: Noah Misch
Date:
Subject: Re: conchuela timeouts since 2021-10-09 system upgrade