From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |
Date: | 2021-07-31 08:51:44 |
Message-ID: | CAH2-Wz=Et8WLvS6d7-BH_yT9b5=cV89fXBmY0T-KgsT7R0=R_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, Jul 31, 2021 at 11:37 AM Andrey Borodin <x4mmm(at)yandex-team(dot)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:
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
From | Date | Subject | |
---|---|---|---|
Next Message | Rui An | 2021-07-31 19:30:14 | Many queries stuck for waiting MultiXactOffsetControlLock on PostgreSQL 9.6.1 replica |
Previous Message | Andrey Borodin | 2021-07-31 08:37:50 | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |