From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash
Date: Tue, 21 Feb 2023 19:00:07 -0500
Message-ID: <4111538.1677024007@sss.pgh.pa.us> (raw)
In-Reply-To: <20230221233349.lj3btvtyqog5jzxd@awork3.anarazel.de>
References: <17800-ff90866b3906c964@postgresql.org>
<Y/P49Yov2m+VzfFf@paquier.xyz>
<20230221193352.mvzpuvoujfmckvr3@awork3.anarazel.de>
<3990862.1677010571@sss.pgh.pa.us>
<20230221204201.idad3kjv3ue7gb6s@awork3.anarazel.de>
<3995669.1677012915@sss.pgh.pa.us>
<20230221221602.42n3pheoafjsmouj@awork3.anarazel.de>
<4060951.1677018870@sss.pgh.pa.us>
<20230221233349.lj3btvtyqog5jzxd@awork3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> Perhaps we should deal with this by generating a distinct type of expression
> step, that looks up information about the param in a different place? Nothing
> forces us to have the expression step look into
> prm = &(econtext->ecxt_param_exec_vals[op->d.param.paramid]);
Right, where I was going was to have a distinct EEOP type that finds
the ParamExecData in some other way. The main question is where to keep
that not-so-global ParamExecData.
>> Another idea I'm toying with is that the expression compiler could
>> allocate some space when it sees a MULTIEXPR_SUBLINK, and then
>> connect up the multiexec Params to that.
> Where are you thinking of getting the information for connecting the params
> from? I don't think we currently have a good way to figure that out during
> evaluation time, right?
It would have to look something like the forward-jump fixup logic,
that is keep track of unfinished Param-referencing steps and go back
to fill them in when it finds the driving MULTIEXPR_SUBLINK and allocates
some space to hold the output of that. A lot of details still to be
filled in there, but it doesn't seem very different from stuff we're
already doing.
regards, tom lane
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: tgl@sss.pgh.pa.us, andres@anarazel.de, michael@paquier.xyz, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash
In-Reply-To: <4111538.1677024007@sss.pgh.pa.us>
* 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