Re: Adding REPACK [concurrently]
| От | Antonin Houska |
|---|---|
| Тема | Re: Adding REPACK [concurrently] |
| Дата | |
| Msg-id | 4200.1772781295@localhost обсуждение исходный текст |
| Ответ на | Re: Adding REPACK [concurrently] (Antonin Houska <ah@cybertec.at>) |
| Список | pgsql-hackers |
Antonin Houska <ah@cybertec.at> wrote: > Srinath Reddy Sadipiralla <srinath2133@gmail.com> wrote: > > > The concurrency test failed once. I tried to reproduce the below scenario > > but no luck,i think the reason the assert failure happened because > > after speculative insert there might be no spec CONFIRM or ABORT, thoughts? > > Perhaps, I'll try. I'm not sure the REPACK decoding worker does anthing > special regarding decoding. If you happen to see the problem again, please try > to preserve the related WAL segments - if this is a bug in PG executor, > pg_waldump might reveal that. I could not reproduce the failure, and have no idea how speculative insert can stay w/o CONFIRM / ABORT record. The only problem I could imagine is that change_useless_for_repack() filters out the CONFIRM / ABORT record accidentally, but neither code review nor debugger proves that theory. (Actually if this was the problem, the test failure probably wouldn't be that rare.) -- Antonin Houska Web: https://www.cybertec-postgresql.com
В списке pgsql-hackers по дате отправления: