Re: SegFault on 9.6.14 - Mailing list pgsql-hackers
From | Thomas Munro |
---|---|
Subject | Re: SegFault on 9.6.14 |
Date | |
Msg-id | CA+hUKG+UkjUyC6mXNmU=51g0vgPBL=n4RCf_ncyTJFPA7it1DQ@mail.gmail.com Whole thread Raw |
In response to | Re: SegFault on 9.6.14 (Alvaro Herrera <alvherre@2ndquadrant.com>) |
List | pgsql-hackers |
On Tue, Aug 13, 2019 at 7:07 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > 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. Right, AIUI we hold onto that memory because it's a nice optimisation to be able to rescan the sorted data or reuse the hash table (single batch, non-parallel hash joins only for now). We have no disincentive, because our memory model doesn't care about the total peak memory usage (ie all nodes). Some other RDBMSs do care about that, and somehow consider the peak memory usage (that is, considering early memory release) when comparing join orders. However, I think it's independent of the DSM lifetime question, because the main Parallel Context DSM segment is really small, it has a small fixed header and then a small object per parallel-aware node, and isn't used for holding the hash table for Parallel Hash and probably wouldn't be used for a future hypothetical Parallel Sort (if it's implemented the way I imagine at least). It contains a DSA area, which creates more DSM segments as it needs them, and nodes can opt to free DSA memory sooner, which will likely result in those extra DSM segments being freed; you can see that happening in Parallel Hash which in fact does give back memory quite eagerly. (I'm the first to admit that it's weird that DSM segments can hold DSA areas and DSA areas are made up of DSM segments; that falls out of the choice to use DSM segments both for storage and as a lifetime management system for shared resources, and I wouldn't be surprised if we reconsider that as we get more experience and ideas.) -- Thomas Munro https://enterprisedb.com
pgsql-hackers by date: