Re: assertion failure at cost_memoize_rescan()

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Kohei KaiGai <kaigai(at)heterodb(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: assertion failure at cost_memoize_rescan()
Date: 2024-06-18 03:14:02
Message-ID: CAMbWs4-TR63+cq8PB1ZuBP7ND39SxVO6uHAHwvfb+Xn-7ieU-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 18, 2024 at 10:53 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> Out of the places I saw, it seems we do tend to code things so that we
> don't assume the value has been clamped. E.g.
> adjust_limit_rows_costs() does if (*rows < 1) *rows = 1;

Agreed. In costsize.c I saw a few instances where we have

/* Protect some assumptions below that rowcounts aren't zero */
if (inner_path_rows <= 0)
inner_path_rows = 1;

> I think the best solution is to apply the attached. I didn't test,
> but it should fix the issue you reported and also ensure that
> MemoizePath.calls is never zero, which would also cause issues in the
> hit_ratio calculation in cost_memoize_rescan().

+1.

Thanks
Richard

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2024-06-18 03:59:10 Re: State of pg_createsubscriber
Previous Message Nathan Bossart 2024-06-18 03:06:59 Re: New GUC autovacuum_max_threshold ?