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
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 ? |