Re: SegFault on 9.6.14
От
Alvaro Herrera
Тема
Re: SegFault on 9.6.14
Дата
Msg-id
20190812190749.GA13961@alvherre.pgsql
Ответ на
Re: SegFault on 9.6.14 (Thomas Munro)
Список
Дерево обсуждения
SegFault on 9.6.14 Jerry Sievers <gsievers19@comcast.net>
Re: SegFault on 9.6.14 Tomas Vondra <tomas.vondra@2ndquadrant.com>
Re: SegFault on 9.6.14 Jerry Sievers <gsievers19@comcast.net>
Re: SegFault on 9.6.14 Tomas Vondra <tomas.vondra@2ndquadrant.com>
Re: SegFault on 9.6.14 Jerry Sievers <gsievers19@comcast.net>
Re: SegFault on 9.6.14 Tomas Vondra <tomas.vondra@2ndquadrant.com>
Re: SegFault on 9.6.14 Jerry Sievers <gsievers19@comcast.net>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Jerry Sievers <gsievers19@comcast.net>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Jerry Sievers <gsievers19@comcast.net>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Jerry Sievers <gsievers19@comcast.net>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Jerry Sievers <gsievers19@comcast.net>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Tom Lane <tgl@sss.pgh.pa.us>
Re: SegFault on 9.6.14 Robert Haas <robertmhaas@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Tom Lane <tgl@sss.pgh.pa.us>
Re: SegFault on 9.6.14 vignesh C <vignesh21@gmail.com>
Re: SegFault on 9.6.14 Robert Haas <robertmhaas@gmail.com>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Alvaro Herrera <alvherre@2ndquadrant.com>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Robert Haas <robertmhaas@gmail.com>
Re: SegFault on 9.6.14 Tom Lane <tgl@sss.pgh.pa.us>
Re: SegFault on 9.6.14 Robert Haas <robertmhaas@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Tom Lane <tgl@sss.pgh.pa.us>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Tom Lane <tgl@sss.pgh.pa.us>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Robert Haas <robertmhaas@gmail.com>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Amit Kapila <amit.kapila16@gmail.com>
Re: SegFault on 9.6.14 Jerry Sievers <gsievers19@comcast.net>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
Re: SegFault on 9.6.14 Thomas Munro <thomas.munro@gmail.com>
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 по дате отправления
От: Alexander Korotkov
Дата: