| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
| Subject: | Re: Atomics for heap_parallelscan_nextpage() |
| Date: | 2017-08-16 19:43:09 |
| Message-ID: | 24293.1502912589@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On 08/16/2017 09:00 PM, Tom Lane wrote:
>> I don't buy that argument. A caller might think "Why do I need
>> shm_toc_estimate, when I can compute the *exact* size I need?".
>> And it would have worked, up till this proposed patch.
> Well, no. The size of the shm_toc struct is subtracted from the size
> that you give to shm_toc_create. As well as the sizes of the TOC
> entries. And those sizes are private to shm_toc.c, so a caller has no
> way to know what size it should pass to shm_toc_create(), in order to
> have N bytes of space actually usable. You really need to use
> shm_toc_estimate() if you want any guarantees on what will fit.
Good point --- objection withdrawn.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-08-16 19:44:50 | Re: Garbled comment in postgresGetForeignJoinPaths |
| Previous Message | Tom Lane | 2017-08-16 19:40:50 | Re: distinct estimate of a hard-coded VALUES list |