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

Andrey Borodin <x4mmm@yandex-team.ru>

From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
Cc: Noah Misch <noah@leadboat.com>, 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>, Andres Freund <andres@anarazel.de>, Semab Tariq <semab.tariq@enterprisedb.com>
Date: 2021-10-31T19:01:08Z
Lists: pgsql-bugs

> 31 окт. 2021 г., в 12:31, Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> написал(а):
> 
> Here is the stack trace:
Thanks Sandeep!

So far I didn't come up with a clear understanding how this might happen.

The only idea I have:
1. It seems equalTupleDescs() got two valid pointers, probably with broken data.
2. Maybe relation->rd_rel (alloceted just before relation->rd_att) was used incorrectly?
3. This could happen if CLASS_TUPLE_SIZE is calculated wrong. Don't we need to MAXALIGN everything due to added sizeof(relminmxid)?
#define CLASS_TUPLE_SIZE \
     (offsetof(FormData_pg_class,relminmxid) + sizeof(TransactionId))

The idea doesn't seem very strong but that's only 2 cents I have. Noah, what do you think?

Best regards, Andrey Borodin.


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Improve contrib/amcheck's tests for CREATE INDEX CONCURRENTLY.

  2. Fix minor memory leaks in pg_dump.

  3. Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.

  4. Fix CREATE INDEX CONCURRENTLY for the newest prepared transactions.

  5. Add -w back to the flags for pg_ctl (re)start in PostgresNode

  6. Fix CREATE INDEX CONCURRENTLY for simultaneous prepared transactions.