Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash
Дата
Msg-id 4111538.1677024007@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash  (Andres Freund <andres@anarazel.de>)
Ответы Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash  (Andres Freund <andres@anarazel.de>)
Список pgsql-bugs
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



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers