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

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Noah Misch <noah@leadboat.com>, Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2021-07-31T08:51:44Z
Lists: pgsql-bugs
On Sat, Jul 31, 2021 at 11:37 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> I'll try. This bug is #1 priority for me. We repack ~pb of indexes each weekend (only bloated, many in fact are bloated). And seems like they all are endangered.

I have a tip, which might make life a little easier: maybe use rr for this? See:

https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Recording_Postgres_using_rr_Record_and_Replay_Framework

Having a stable recording with fixed logical times *vastly* simplifies
debugging in practice. I found this very useful when debugging the SSI
Jepsen bug, which was a complex race condition that could only be
reproduced through a complex procedure. Which is also what we have
here now, more or less. Your personal notes on the bug can sensibly
track specific pointer values, logical times, etc.

You can even "pack" a recording, making it into a self-contained thing
that doesn't rely on having the original binaries. This makes the
recording stable enough to keep for weeks or months, share with other
people, etc.

-- 
Peter Geoghegan



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.