Re: snapshot too old issues, first around wraparound and then more.
От | Peter Geoghegan |
---|---|
Тема | Re: snapshot too old issues, first around wraparound and then more. |
Дата | |
Msg-id | CAH2-Wznz_uBRoPvtTu47Z3mFTHXSbTagQ-15BC+hpCiFtKvi=w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: snapshot too old issues, first around wraparound and then more. (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Wed, Apr 1, 2020 at 4:59 PM Andres Freund <andres@anarazel.de> wrote: > Thanks, that's super helpful. Glad I could help. > I got a bit confused here - you seemed to have switched session 1 and 2 > around? Doesn't seem to matter much though, I was able to reproduce this. Yeah, I switched the session numbers because I was in a hurry. Sorry about that. As you have already worked out, one session does all the DDL and initial loading of data, while the other session queries the data repeatedly in a serializable (or RR) xact. The latter session exhibits the bug. > This indeed seems a separate bug. > The primary issue here is that there is no TestForOldSnapshot() in > heap_hot_search_buffer(). Therefore index fetches will never even try to > detect that tuples it needs actually have already been pruned away. I suspected that heap_hot_search_buffer() was missing something. > The wrong queries I saw took longer to reproduce, so I've not been able > to debug the precise reasons. How hard would it be to write a debug patch that reduces the quantum used in places like TransactionIdLimitedForOldSnapshots() to something much less than the current 1 minute quantum? That made reproducing the bug *very* tedious. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: