Re: [HACKERS] Parallel bitmap heap scan
| От | Tom Lane | 
|---|---|
| Тема | Re: [HACKERS] Parallel bitmap heap scan | 
| Дата | |
| Msg-id | 3114.1487617490@sss.pgh.pa.us обсуждение исходный текст | 
| Ответ на | Re: [HACKERS] Parallel bitmap heap scan (Robert Haas <robertmhaas@gmail.com>) | 
| Список | pgsql-hackers | 
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Feb 20, 2017 at 6:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The thing that you really have to worry about for this kind of proposal
>> is "what if the query errors out and we never get to ExecEndNode"?
>> It's particularly nasty if you're talking about parallel queries where
>> maybe only one or some of the processes involved detect an error.
> I think that's not actually a problem, because we've already got code
> to make sure that all DSM resources associated with the query get
> blown away in that case.  Of course, that code might have bugs, but if
> it does, I think it's better to try to fix those bugs than to insert
> some belt-and-suspenders mechanism for reclaiming every possible chunk
> of memory in retail fashion, just like we blow up es_query_cxt rather
> than trying to pfree allocations individually.
Actually, I think we're saying the same thing: rely on the general DSM
cleanup mechanism, don't insert extra stuff that you expect will get
done by executor shutdown.
        regards, tom lane
		
	В списке pgsql-hackers по дате отправления: