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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Allow Postgres to pick an unused port to listen
Следующее
От: Andres Freund
Дата:
Сообщение: testing sepgsql in CI