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
