| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
| 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:22:40 |
| Message-ID: | 700541.1618971760@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> writes:
> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>> No. You'd have to be superuser anyway to do that, and we're not in the
>> habit of trying to put training wheels on superusers.
> Understood. However, we may add the parallel safety member in fmgr_builtins[] in another thread for parallel INSERT SELECT. I'd appreciate your comment on this if you see any concern.
[ 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-04-21 02:30:20 | Re: Docs: Move parallel_leader_participation GUC description under relevant category |
| Previous Message | Amit Langote | 2021-04-21 02:13:06 | Re: Table refer leak in logical replication |