Re: Postgres 16.1 - Bug: cache entry already complete
От | David Rowley |
---|---|
Тема | Re: Postgres 16.1 - Bug: cache entry already complete |
Дата | |
Msg-id | CAApHDvp4gytizu18eqxaSxE56KwjG4vssEs6GPTq6_8SpgQhRw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Postgres 16.1 - Bug: cache entry already complete (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: Postgres 16.1 - Bug: cache entry already complete
|
Список | pgsql-bugs |
On Thu, 4 Jan 2024 at 00:01, Richard Guo <guofenglinux@gmail.com> wrote: > if (extra->inner_unique && > (inner_path->param_info == NULL || > list_length(inner_path->param_info->ppi_clauses) < > list_length(extra->restrictlist))) > return NULL; I see. So it worked fine until Tom's " Make Vars be outer-join-aware." stuff. 9e215378d fixed this already and looks like I came to the same conclusion about the cache completion issue back then too. > But why does the code above fail to capture the problematic query? It > turns out that inner_path->param_info->ppi_clauses contains cloned > clauses, i.e. multiple versions of the same clause in order to cope with > outer join identity 3. And this causes the above code to give incorrect > conclusions about the length of 'ppi_clauses'. And this also explains > why this issue only occurs in v16. > > As a clause's serial number is unique within the current PlannerInfo > context, and multiple clones of the same clause have the same serial > number, it seems to me that it's more correct to calculate the length of > ppi_clauses by: > > bms_num_members(inner_path->param_info->ppi_serials) > > So I think maybe we can fix this issue with the attached patch. hmm, I'd need to study what Tom's been changing around this. I don't have a good handle on which qual lists can have duplicated quals. In [1], you can see I took the inspiration for that fix from generate_mergejoin_paths(). I don't yet know if it's just ppi_clauses that can have duplicates or if there's a similar hazard in the list_length() checks in generate_mergejoin_paths() > BTW, the SingleRow in explain seems quite handy. I wonder if we can > keep it. If the fix is to just disable Memoize when the ppi_clauses don't cover the entire join condition, then the Inner Unique from the parent nested loop tells us this. Isn't that enough? The reason I added SingleRow was because in the patch I posted, I'd made it so SingleRow could be false in cases where Inner Unique was true. David [1] https://postgr.es/m/CAApHDvrWsfc3naVQZxS0efU%3DvJOA7dG3NV7fGhkgo2%3DJ38OEpg%40mail.gmail.com
В списке pgsql-bugs по дате отправления: