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

From: Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, CM Team <cm(at)enterprisedb(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>, Semab Tariq <semab(dot)tariq(at)enterprisedb(dot)com>
Subject: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Date: 2021-11-01 13:10:04
Message-ID: CANFyU97socOyfjyhS6ZYvguBdP=Fqqu-SK2z1_QT4t7-P5qzLQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Nov 1, 2021 at 12:48 AM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2021-10-31 13:01:00 +0530, Sandeep Thakkar wrote:
> > > #1 0x40000000003fdc00:0 in equalTupleDescs
> (tupdesc1=0x60000000001f65e0,
> > >
> > > tupdesc2=0x60000000001fba08)
>
> Could you print out *tupdesc1, *tupdesc2? And best also
> p tupdesc1->attrs[0]
> p tupdesc1->attrs[1]
> p tupdesc1->attrs[2]
> p tupdesc2->attrs[0]
> p tupdesc2->attrs[1]
> p tupdesc2->attrs[2]
>
> you mean make the changes in the .c files to print these values and rerun
the build? Can you please share the files where this needs to be done or
give me a patch?

>
> > > #2 0x40000000017f9660:0 in RelationClearRelation (
> > >
> > > relation=0x60000000001f3730, rebuild=true)
>
> Hm, too bad that we don't have working line numbers for some reason?
>
>
> > > #3 0x40000000017fa730:0 in RelationFlushRelation
> > > (relation=0x60000000001f3730)
> > >
> > > #4 0x40000000017fabb0:0 in RelationCacheInvalidateEntry
> > > (relationId=27272)
> > >
> > > #5 0x40000000017c8f20:0 in LocalExecuteInvalidationMessage (
> > >
> > > msg=0x60000000001a46b8)
> > >
> > > #6 0x40000000017c84e0:0 in ProcessInvalidationMessages (
> > >
> > > group=0x60000000001a43e4, func=0x87ffffffef7b7250)
> > >
> > > #7 0x40000000017cb420:0 in CommandEndInvalidationMessages ()
> > >
> > > #8 0x40000000006b1c50:0 in AtCCI_LocalCache ()
> > >
> > > #9 0x40000000006b0910:0 in CommandCounterIncrement ()
> > >
> > > #10 0x4000000000807130:0 in create_toast_table (rel=0x60000000001f3730,
> > >
> > > toastOid=0, toastIndexOid=0, reloptions=0, lockmode=8, check=true,
> > >
> > > OIDOldToast=0)
> > >
> > > #11 0x4000000000805ac0:0 in CheckAndCreateToastTable (relOid=27272,
> > >
> > > reloptions=0, lockmode=8, check=true, OIDOldToast=0) at
> toasting.c:88
> > >
> > > #12 0x4000000000805850:0 in AlterTableCreateToastTable (relOid=27272,
> > >
> > > reloptions=0, lockmode=8) at toasting.c:62
> > >
> > > #13 0x4000000000aa9a30:0 in ATRewriteCatalogs
> (wqueue=0x87ffffffffffc3b0,
> > >
> > > lockmode=8, context=0x87ffffffffffc590)
>
>
> This crash could suggest that somehow the catalogs were corrupted and
> that we're not reading back valid tupledescs from them. Hopefully we'll
> know more after looking at the tupledescs.
>
>
> Greetings,
>
> Andres Freund
>

--
Sandeep Thakkar

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Borodin 2021-11-01 13:18:18 Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Previous Message Pavel Borisov 2021-11-01 08:47:51 Re: BUG #17245: Index corruption involving deduplicated entries