Re: SegFault on 9.6.14 - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: SegFault on 9.6.14
Date
Msg-id 20190812190749.GA13961@alvherre.pgsql
Whole thread Raw
In response to Re: SegFault on 9.6.14  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: SegFault on 9.6.14  (Robert Haas <robertmhaas@gmail.com>)
Re: SegFault on 9.6.14  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On 2019-Aug-12, Thomas Munro wrote:

> That's possibly relevant because it means we'd have a ParallelContext
> or some new overarching object that has a lifetime that is longer than
> the individual Gather nodes' processes and instrumentation data.  I'm
> not saying we need to discuss any details of this other concern now,
> I'm just wondering out loud if the whole problem in this thread goes
> away automatically when we fix it.

How likely is it that we would ever be able to release memory from a
Sort (or, say, a hashjoin hash table) when it's done being read, but
before completing the whole plan?  As I understand, right now we hold
onto a lot of memory after such plans have been fully read, for no good
reason other than executor being unaware of this.  This might not be
directly related to the problem at hand, since it's not just parallel
plans that are affected.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Improve search for missing parent downlinks in amcheck
Next
From: Alexander Korotkov
Date:
Subject: Re: Support for jsonpath .datetime() method