Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Дата
Msg-id 20211107232202.GA882747@rfd.leadboat.com
обсуждение исходный текст
Ответ на Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data  (Semab Tariq <semab.tariq@enterprisedb.com>)
Ответы Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Список pgsql-bugs
On Sun, Nov 07, 2021 at 08:25:09PM +0500, Semab Tariq wrote:
> On Sun, Nov 7, 2021 at 4:08 AM Noah Misch <noah@leadboat.com> wrote:
> > On Fri, Nov 05, 2021 at 04:22:36AM -0700, Noah Misch wrote:
> > > On Fri, Nov 05, 2021 at 03:21:15PM +0500, Semab Tariq wrote:
> > > > Breakpoint 1, 0x40000000003fcb50:0 in equalTupleDescs (
> > > >     tupdesc1=0x40010006f968, tupdesc2=0x87ffffffffffac50)
> > >
> > > The addresses there are weird.  tupdesc1 is neither a stack address nor a heap
> > > address; it may be in a program text section.  tupdesc2 is a stack address.
> > > In the earlier stack trace from
> > > https://postgr.es/m/CANFyU94Xa8a5+4sZ7PxOiDLq+yN89g6y-9nNk-eLEvX6YUXbXA@mail.gmail.com
> > > both tupdesc1 and tupdesc2 were heap addresses.

That turned out to be a false alarm.  On gharial, a breakpoint at the start of
the function doesn't see the real arguments.  After a ten-instruction
prologue, the real arguments appear, and they are heap addresses.

> PFA new regress_log_080_step_equalTupleDescs file generated from your latest patch

Thanks.  That shows the crash happened sometime after strcmp(defval1->adbin,
defval2->adbin).  Please run the attached version, which collects yet more
information.

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Maxim Boguk
Дата:
Сообщение: Re: BUG #17268: Possible corruption in toast index after reindex index concurrently
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: BUG #17245: Index corruption involving deduplicated entries