From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ilya Anfimov <ilan(at)tzirechnoy(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17646: create rule named "_RETURN" will cause pg core |
Date: | 2022-10-17 14:41:35 |
Message-ID: | 2173460.1666017695@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Ilya Anfimov <ilan(at)tzirechnoy(dot)com> writes:
> On Mon, Oct 17, 2022 at 10:17:55AM -0400, Tom Lane wrote:
>> (Although the core dump is also not great --- something should've noticed
>> the bogosity of the plan earlier than this.)
> Id doesn't look much of a plan bogosity,
> but rather implicit deletion of the "_RETURN" on select rule.
Right, but then since there's no applicable rule, we end up generating
a plan that tries to do a seqscan directly on the view relation,
which of course lacks storage. Something should notice that a little
sooner than segfaulting because of rel->rd_tableam being NULL --- it's
not like we don't have hundreds of other sanity checks for not-really-
supposed-to-happen catalog corruption.
In versions before v12, I get something like
regression=# select * from v1;
ERROR: could not open file "base/16384/49209": No such file or directory
which is a shade less bad, but still not great.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ilya Anfimov | 2022-10-17 15:15:57 | Re: BUG #17646: create rule named "_RETURN" will cause pg core |
Previous Message | Ilya Anfimov | 2022-10-17 14:38:38 | Re: BUG #17646: create rule named "_RETURN" will cause pg core |