Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
От | Peter Geoghegan |
---|---|
Тема | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |
Дата | |
Msg-id | CAH2-Wz=Et8WLvS6d7-BH_yT9b5=cV89fXBmY0T-KgsT7R0=R_A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data (Andrey Borodin <x4mmm@yandex-team.ru>) |
Ответы |
Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |
Список | 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
В списке pgsql-bugs по дате отправления: