RE: [bug?] Missed parallel safety checks, and wrong parallel safety

From: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
To: 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: [bug?] Missed parallel safety checks, and wrong parallel safety
Date: 2021-04-21 02:41:58
Message-ID: OSAPR01MB2977CF3DF248D5749D4C4318FE479@OSAPR01MB2977.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> [ raised eyebrow... ] I find it very hard to understand why that would
> be necessary, or even a good idea. Not least because there's no spare
> room there; you'd have to incur a substantial enlargement of the
> array to add another flag. But also, that would indeed lock down
> the value of the parallel-safety flag, and that seems like a fairly
> bad idea.

You're right, FmgrBuiltins is already fully packed (24 bytes on 64-bit machines). Enlarging the frequently accessed fmgr_builtins array may wreak unexpectedly large adverse effect on performance.

I wanted to check the parallel safety of functions, which various objects (data type, index, trigger, etc.) come down to, in FunctionCallInvoke() and other few places. But maybe we skip the check for built-in functions. That's a matter of where we draw a line between where we check and where we don't.

Regards
Takayuki Tsunakawa

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-04-21 02:50:35 Re: Is it worth to optimize VACUUM/ANALYZE by combining duplicate rel instances into single rel instance?
Previous Message Bharath Rupireddy 2021-04-21 02:35:37 Re: Docs: Move parallel_leader_participation GUC description under relevant category