On 2016-03-16 11:02:09 -0700, Joshua D. Drake wrote:
> >>3. The problem can get worse over time. If you have a very long running
> >>instance, any time the backend crash-restarts you have to potential to
> >>increase disk space used for no purpose.
> >
> >But I think these outweigh the debugging be
On 03/16/2016 11:04 AM, Andres Freund wrote:
On 2016-03-16 11:02:09 -0700, Joshua D. Drake wrote:
3. The problem can get worse over time. If you have a very long running
instance, any time the backend crash-restarts you have to potential to
increase disk space used for no purpose.
But I think
On 03/16/2016 10:56 AM, Andres Freund wrote:
I understand that this is designed this way. I think it is a bad idea
because:
1. The majority crash-restarts in the wild are going to be diagnosed rather
easily within the OS itself. They fall into things like OOM killer and out
of disk space.
I d
On Wed, Mar 16, 2016 at 2:05 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> Hello,
>> fd.c[1] will remove files from pgsql_tmp on a restart but not a
>> crash-restart per this comment:
>
>> /*
>> * NOTE: we could, but don't, call this during a post-backend-crash restart
>> * cycle. The argum
On Wed, Mar 16, 2016 at 10:53 AM, Joshua D. Drake
wrote:
> fd.c[1] will remove files from pgsql_tmp on a restart but not a
> crash-restart per this comment:
>
> /*
> * NOTE: we could, but don't, call this during a post-backend-crash restart
> * cycle. The argument for not doing it is that someon
Hello,
fd.c[1] will remove files from pgsql_tmp on a restart but not a
crash-restart per this comment:
/*
* NOTE: we could, but don't, call this during a post-backend-crash restart
* cycle. The argument for not doing it is that someone might want to
examine
* the temp files for debugging pu
On 2016-03-16 11:06:23 -0700, Joshua D. Drake wrote:
> On 03/16/2016 11:04 AM, Andres Freund wrote:
> >On 2016-03-16 11:02:09 -0700, Joshua D. Drake wrote:
> 3. The problem can get worse over time. If you have a very long running
> instance, any time the backend crash-restarts you have to p
On 2016-03-16 10:53:42 -0700, Joshua D. Drake wrote:
> Hello,
>
> fd.c[1] will remove files from pgsql_tmp on a restart but not a
> crash-restart per this comment:
>
> /*
> * NOTE: we could, but don't, call this during a post-backend-crash restart
> * cycle. The argument for not doing it is that
"Joshua D. Drake" writes:
> Hello,
> fd.c[1] will remove files from pgsql_tmp on a restart but not a
> crash-restart per this comment:
> /*
> * NOTE: we could, but don't, call this during a post-backend-crash restart
> * cycle. The argument for not doing it is that someone might want to
> exam
On 03/16/2016 11:08 AM, Andres Freund wrote:
Well as Andrew said, we could also create postmaster start option that
defaults to don't save.
I think these days you'd simply use restart_after_crash = false. For
debugging I found that to be rather valuable.
That would have created an extended o
On 3/16/16 2:16 PM, Tom Lane wrote:
Robert Haas writes:
On Wed, Mar 16, 2016 at 2:05 PM, Tom Lane wrote:
Possible compromise: remove files only in non-Assert builds?
That sorta seems like tying two things together that aren't obviously
related. I think building with --enable-cassert is su
On 03/16/2016 11:05 AM, Tom Lane wrote:
"Joshua D. Drake" writes:
Hello,
fd.c[1] will remove files from pgsql_tmp on a restart but not a
crash-restart per this comment:
/*
* NOTE: we could, but don't, call this during a post-backend-crash restart
* cycle. The argument for not doing it is th
Robert Haas writes:
> On Wed, Mar 16, 2016 at 2:05 PM, Tom Lane wrote:
>> Possible compromise: remove files only in non-Assert builds?
> That sorta seems like tying two things together that aren't obviously
> related. I think building with --enable-cassert is support to enable
> debugging cross
13 matches
Mail list logo
