Re: file_fdw: Fix ANALYZE crashes with DEFAULT markers

From: Ayoub Kazar <ayoub(dot)kazar(at)data-bene(dot)io>
To: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: file_fdw: Fix ANALYZE crashes with DEFAULT markers
Date: 2026-11-04 23:18:19
Message-ID: 9ebbaec8-46eb-4d82-b4f6-3f72a0544b2f@data-bene.io
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Fujii and Jim,

I can confirm reproduction aswell (planned to report it tomorrow but
Fujii beat me to it).
There's also another bug very close to this code: ANALYZE does not
enforce REJECT_LIMIT when on_error 'ignore' is enabled.
That's for a different unrelated commit, i'll report this soon, if it
interests you to take a look.

On 04/11/2026 16:26, Jim Jones wrote:

> On 04/11/2026 14:37, Fujii Masao wrote:
>> Yeah, since AFAICT there seems no need to invoke registered callbacks,
>> ResetExprContext() might be sufficient. Also, ResetPerTupleExprContext()
>> would be better for consistency with CopyFrom(), which uses it?
>>
> IIUC es_per_tuple_exprcontext will always be non-NULL because of
> GetPerTupleExprContext(), so in theory the extra check in
> ResetPerTupleExprContext() is a bit redundant, but I agree it's a good
> idea to keep the code consistent.
This also applies to:
- MemoryContextSwitchTo(econtext->ecxt_per_tuple_memory);
+ MemoryContextSwitchTo(GetPerTupleMemoryContext(estate));

For the same exact reasons, it stays consistent with
fileIterateForeignScan(), if we want of course...

Regards,
Ayoub Kazar

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Manu 2026-11-04 23:46:49 Re: Do we need an index on pg_constraint.confrelid?
Previous Message Ethan Tran 2026-11-04 23:05:00 Re: [PATCH]Fix planner's strictness check for JsonExpr