Re: WIP: WAL prefetch (another approach)
От | Tom Lane |
---|---|
Тема | Re: WIP: WAL prefetch (another approach) |
Дата | |
Msg-id | 477464.1637981215@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP: WAL prefetch (another approach) (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: WIP: WAL prefetch (another approach)
Re: WIP: WAL prefetch (another approach) |
Список | pgsql-hackers |
Thomas Munro <thomas.munro@gmail.com> writes: > On Sat, Nov 27, 2021 at 12:34 PM Tomas Vondra > <tomas.vondra@enterprisedb.com> wrote: >> One thing that's not clear to me is what happened to the reasons why >> this feature was reverted in the PG14 cycle? > 3. A wild goose chase for bugs on Tom Lane's antique 32 bit PPC > machine. Tom eventually reproduced it with the patches reverted, > which seemed to exonerate them but didn't leave a good feeling: what > was happening, and why did the patches hugely increase the likelihood > of the failure mode? I have no new information on that, but I know > that several people spent a huge amount of time and effort trying to > reproduce it on various types of systems, as did I, so despite not > reaching a conclusion of a bug, this certainly contributed to a > feeling that the patch had run out of steam for the 14 cycle. Yeah ... on the one hand, that machine has shown signs of hard-to-reproduce flakiness, so it's easy to write off the failures I saw as hardware issues. On the other hand, the flakiness I've seen has otherwise manifested as kernel crashes, which is nothing like the consistent test failures I was seeing with the patch. Andres speculated that maybe we were seeing a kernel bug that affects consistency of concurrent reads and writes. That could be an explanation; but it's just evidence-free speculation so far, so I don't feel real convinced by that idea either. Anyway, I hope to find time to see if the issue still reproduces with Thomas' new patch set. regards, tom lane
В списке pgsql-hackers по дате отправления: