Re: Wrong results from Parallel Hash Full Join
От | Andres Freund |
---|---|
Тема | Re: Wrong results from Parallel Hash Full Join |
Дата | |
Msg-id | 20230412181452.cyfduw2ka2atqmii@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Wrong results from Parallel Hash Full Join (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: Wrong results from Parallel Hash Full Join
|
Список | pgsql-hackers |
Hi, On 2023-04-12 10:57:17 -0400, Melanie Plageman wrote: > HeapTupleHeaderHasMatch() checks if HEAP_TUPLE_HAS_MATCH is set. > > In htup_details.h, you will see that HEAP_TUPLE_HAS_MATCH is defined as > HEAP_ONLY_TUPLE > /* > * HEAP_TUPLE_HAS_MATCH is a temporary flag used during hash joins. It is > * only used in tuples that are in the hash table, and those don't need > * any visibility information, so we can overlay it on a visibility flag > * instead of using up a dedicated bit. > */ > #define HEAP_TUPLE_HAS_MATCH HEAP_ONLY_TUPLE /* tuple has a join match */ > > If you redefine HEAP_TUPLE_HAS_MATCH as something that isn't already > used, say 0x1800, the query returns correct results. > [...] > The question is, why does this only happen for a parallel full hash join? I'd guess that PHJ code is missing a HeapTupleHeaderClearMatch() somewhere, but the non-parallel case isn't. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: