Re: signal 11 segfaults with parallel workers

From: Rick Otten <rottenwindfish(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: signal 11 segfaults with parallel workers
Date: 2017-07-30 21:25:41
Message-ID: CAMAYy4LaWA8nSWxpgaMp4F-E0uoB2PAstPXidVbQdhq-T7Fagw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Well, I'm not sure how to inspect the temp tablespace other than from the
filesystem itself. I have it configured on its own disk. Usually the disk
space ebbs and flows with query activity. Since we've been crashing
however, it never reclaims the disk that was in use just before the crash.
So our temp space 'floor" keeps getting higher and higher.

At least that is what it has been doing for the past week or two, and what
it looked like this morning. Now that the database has been back up for 8
or 9 hours following this controlled restart, I just went to look at it,
and all of the temp space has been reclaimed - for the first time since the
crashing started. ... Interesting...

On Sun, Jul 30, 2017 at 11:22 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Rick Otten <rottenwindfish(at)gmail(dot)com> writes:
> > One thing that is bugging me is I think when the database crashes, it
> > doesn't clean up the temp_tablespace(s).
>
> Hm, interesting, what do you see in there?
>
> regards, tom lane
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Masahiko Sawada 2017-07-31 00:40:34 Re: BUG #14758: Segfault with logical replication on a function index
Previous Message Tom Lane 2017-07-30 15:22:53 Re: signal 11 segfaults with parallel workers