Re: [BUGS] signal 11 segfaults with parallel workers - Mailing list pgsql-bugs

From Rick Otten
Subject Re: [BUGS] signal 11 segfaults with parallel workers
Date
Msg-id CAMAYy4LaWA8nSWxpgaMp4F-E0uoB2PAstPXidVbQdhq-T7Fagw@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] signal 11 segfaults with parallel workers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] signal 11 segfaults with parallel workers  (Rick Otten <rottenwindfish@gmail.com>)
List 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@sss.pgh.pa.us> wrote:
Rick Otten <rottenwindfish@gmail.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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] signal 11 segfaults with parallel workers
Next
From: Masahiko Sawada
Date:
Subject: Re: [BUGS] BUG #14758: Segfault with logical replication on afunction index