pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>
Cc: Vik Fearing <vik@postgresfriends.org>
Cc: zuming.jiang@inf.ethz.ch, pgsql-bugs@lists.postgresql.org, Alexander Korotkov <akorotkov@postgresql.org>
Subject: Re: BUG #18170: Unexpected error: no relation entry for relid 3
Date: Mon, 30 Oct 2023 09:43:09 +0700
Message-ID: <99b66244-f939-49ea-b6bf-ecf0440694b7@postgrespro.ru> (raw)
In-Reply-To: <2141583.1698595016@sss.pgh.pa.us>
References: <18170-f1d17bf9a0d58b24@postgresql.org>
	<4ecab120-6be3-4cf6-a2a0-249c73ae91d4@postgresfriends.org>
	<1189851.1698340331@sss.pgh.pa.us>
	<011bcae5-7840-42c7-a50c-b406189e2e78@postgrespro.ru>
	<CAPpHfdsiN0norSHfw3Ujemf=RuPzMxt5PRDiyv0vqUdwSBDtoA@mail.gmail.com>
	<721542ce-79df-469e-93e9-811fadb5bd0c@postgrespro.ru>
	<2eb87c2e-7e6f-4002-8df3-8fac3aa6a037@postgrespro.ru>
	<CAMbWs494m3AjhHry_HFCFi_SJ+6-PaeMRbx7jK39ZHmK0MVOUA@mail.gmail.com>
	<c0a5b39d-8a80-47fb-bd34-6d769f88df8f@postgrespro.ru>
	<CAPpHfduPMdLm42uwuXqM1weUKSYp=2Kf-_XU2TjZsizeZ3qoWQ@mail.gmail.com>
	<CAPpHfdv_6K_sv5sL_=9EiP7Lve81WLSdiLrc22afpmg_whyxtg@mail.gmail.com>
	<2141583.1698595016@sss.pgh.pa.us>

On 29/10/2023 22:56, Tom Lane wrote:
> Alexander Korotkov <aekorotkov@gmail.com> writes:
>> I made some beautification of the patch by Andrei.  I also removed the
>> part which changes the target list for estimate_num_groups().  Any
>> objections to pushing this?
> 
> It seems moderately likely that this will break as much as it fixes.
> 
> I've not studied the original patch enough to understand why you need
> to be playing strange games with tree mutation rules, but I suspect
> that this is band-aiding over some rather fundamentally bad code.

Thank you for the feedback.
I need to confess that it is not clear why keeping two links on the same 
query in a consistent state is a bad idea. If it really is, it would be 
better for future development to explain the reason as a comment in the 
code (because the current problematic procedure was introduced only in [1]).
The doubt I had had about SJE was the cleaning procedure. We are afraid 
of hidden corner cases when deleting relid can be placed elsewhere, or a 
new feature could add more places for this relid. But as an opposite 
reason, we have a better understanding of the planner, a kind of 
self-check of hidden potential bugs. And for me personally, the latter 
is a strong reason. Also, as I see, in the e9a20e4 you wrote the code 
keeping in mind the same idea.

[1] Make Vars be outer-join-aware

-- 
regards,
Andrei Lepikhov
Postgres Professional






view thread (34+ messages)  latest in thread

Message-ID: <99b66244-f939-49ea-b6bf-ecf0440694b7@postgrespro.ru>
Permalink:  ../99b66244-f939-49ea-b6bf-ecf0440694b7@postgrespro.ru/
Also on:    postgresql.org/message-id/99b66244-f939-49ea-b6bf-ecf0440694b7@postgrespro.ru

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: a.lepikhov@postgrespro.ru, tgl@sss.pgh.pa.us, aekorotkov@gmail.com, guofenglinux@gmail.com, vik@postgresfriends.org, akorotkov@postgresql.org
  Subject: Re: BUG #18170: Unexpected error: no relation entry for relid 3
  In-Reply-To: <99b66244-f939-49ea-b6bf-ecf0440694b7@postgrespro.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox