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
>
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 |