Re: Damage control for planner's get_actual_variable_endpoint() runaway
От | Andres Freund |
---|---|
Тема | Re: Damage control for planner's get_actual_variable_endpoint() runaway |
Дата | |
Msg-id | 20221121173048.zqklejzpbeadnmsq@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Damage control for planner's get_actual_variable_endpoint() runaway (Jakub Wartak <jakub.wartak@enterprisedb.com>) |
Ответы |
Re: Damage control for planner's get_actual_variable_endpoint() runaway
Re: Damage control for planner's get_actual_variable_endpoint() runaway |
Список | pgsql-hackers |
Hi, On 2022-11-21 17:06:16 +0100, Jakub Wartak wrote: > @@ -6213,14 +6216,26 @@ get_actual_variable_endpoint(Relation heapRel, > /* Fetch first/next tuple in specified direction */ > while ((tid = index_getnext_tid(index_scan, indexscandir)) != NULL) > { > + BlockNumber block = ItemPointerGetBlockNumber(tid); > if (!VM_ALL_VISIBLE(heapRel, > - ItemPointerGetBlockNumber(tid), > + block, > &vmbuffer)) > { > /* Rats, we have to visit the heap to check visibility */ > if (!index_fetch_heap(index_scan, tableslot)) > continue; /* no visible tuple, try next index entry */ > > + { > + CHECK_FOR_INTERRUPTS(); > + if (block != last_block) > + visited_pages++; > +#define VISITED_PAGES_LIMIT 100 > + if (visited_pages > VISITED_PAGES_LIMIT) > + break; > + else > + continue; /* no visible tuple, try next index entry */ > + } > + > /* We don't actually need the heap tuple for anything */ > ExecClearTuple(tableslot); > > -- > 2.30.2 This can't quite be right - isn't this only applying the limit if we found a visible tuple? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: