Re: BUG #18885: ERROR: corrupt MVNDistinct entry - 2
От | Alexander Korotkov |
---|---|
Тема | Re: BUG #18885: ERROR: corrupt MVNDistinct entry - 2 |
Дата | |
Msg-id | CAPpHfdvhz-p8Wrb0sm+c01Gk2mVR2O-mbbnXDHry4Ax=y1qSTw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18885: ERROR: corrupt MVNDistinct entry - 2 (Andrei Lepikhov <lepihov@gmail.com>) |
Ответы |
Re: BUG #18885: ERROR: corrupt MVNDistinct entry - 2
|
Список | pgsql-bugs |
Hi, Andrei! On Thu, Apr 10, 2025 at 3:28 PM Andrei Lepikhov <lepihov@gmail.com> wrote: > > On 4/9/25 15:46, PG Bug reporting form wrote: > > The following SQL triggers "ERROR: corrupt MVNDistinct entry", however this > > seems to be unrelated to a recent bugfix[1] for a similar issue (thus '2' in > > the $SUBJECT). > That's my fault. > We wanted to avoid using of the add_unique_group_var, but forgot it does > some necessary stuff. > Here, I attempt to use this routine in the hash join bucket size > estimation. I transformed it a little, made it more general. Not sure it > is the best design, but it is debatable. Thank you for the fix, but it's not enough. If you would replace a new regression tests query with this, it would fail with an assertion. SELECT FROM sb_1 LEFT JOIN sb_2 ON (sb_2.x=sb_1.x) AND (sb_1.x=sb_2.x) AND (sb_1.y=sb_2.y); When you use add_unique_group_var() which keeps varinfos unique then you can no longer expect that varinfos have the same order as origin_rinfos. ------ Regards, Alexander Korotkov Supabase
В списке pgsql-bugs по дате отправления: