Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
| От | Corey Huinker |
|---|---|
| Тема | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |
| Дата | |
| Msg-id | CADkLM=c7ya93KcFxAuDp08Ngbyn5n90BHsf=E+5_2EGCubzqsQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |
| Список | pgsql-hackers |
On Wed, Feb 22, 2023 at 5:47 PM Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2023-02-22 16:34:44 -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres@anarazel.de> writes:
> >> Maybe it's worth sticking a StaticAssert() for the struct size
> >> somewhere.
>
> > Indeed. I thought we had one already.
>
> >> I'm a bit wary about that being too noisy, there are some machines with
> >> odd alignment requirements. Perhaps worth restricting the assertion to
> >> x86-64 + armv8 or such?
>
> > I'd put it in first and only reconsider if it shows unfixable problems.
>
> Now that we've got the sizeof(ExprEvalStep) under control, shouldn't
> we do the attached?
Indeed. Pushed.
Let's hope there's no rarely used architecture with odd alignment rules.
Greetings,
Andres Freund
I have a question about this that may affect some of my future work.
My not-ready-for-16 work on CAST( ... ON DEFAULT ... ) involved making FuncExpr/IoCoerceExpr/ArrayCoerceExpr have a safe_mode flag, and that necessitates adding a reserror boolean to ExprEvalStep for subsequent steps to test if the error happened.
Will that change be throwing some architectures over the 64 byte count?
Will that change be throwing some architectures over the 64 byte count?
В списке pgsql-hackers по дате отправления: