Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Semab Tariq <semab.tariq@enterprisedb.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>, Andres Freund <andres@anarazel.de>, CM Team <cm@enterprisedb.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@bowt.ie>
Date: 2021-11-07T23:22:02Z
Lists: pgsql-bugs
Attachments
- step-to-crash-v0.4.patch (text/plain) patch v0
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.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Improve contrib/amcheck's tests for CREATE INDEX CONCURRENTLY.
- b1f943d2aa7e 14.1 landed
- 7f580aa5d88a 15.0 landed
- 5a4b8a8a720c 13.5 landed
- 141cd0ef0b0b 12.9 landed
-
Fix minor memory leaks in pg_dump.
- 70bef494000e 15.0 cited
-
Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.
- e428699cb3be 9.6.24 landed
- db86746fd11e 10.19 landed
- 5141e471b36a 11.14 landed
- dde966efb286 14.1 landed
- 2e33b43599ad 13.5 landed
- 0869e53d3a07 12.9 landed
- fdd965d074d4 15.0 landed
-
Fix CREATE INDEX CONCURRENTLY for the newest prepared transactions.
- df6158139f64 11.14 landed
- 560124a37c2f 10.19 landed
- 5184932432b4 9.6.24 landed
- fe5d44a1d38f 12.9 landed
- a9d0a5409415 13.5 landed
- a5b9a0000e14 14.1 landed
- 3cd9c3b92197 15.0 landed
-
Add -w back to the flags for pg_ctl (re)start in PostgresNode
- b33259e261ae 15.0 cited
-
Fix CREATE INDEX CONCURRENTLY for simultaneous prepared transactions.
- 77a0e14f0b21 9.5.25 landed
- d683d6528dba 9.6.21 landed
- 179775135b41 10.16 landed
- d1ab4bf6ed2d 11.11 landed
- be843ce29737 12.6 landed
- 86a5b309c933 13.2 landed
- 8a54e12a38d1 14.0 landed