On 5 Dec 2014, at 22:41, Jim Nasby wrote:
>
>
> Perhaps we should also officially recommend production servers be setup to
> create core files. AFAIK the only downside is the time it would take to write
> a core that's huge because of shared buffers, but perhaps there's some way to
> avoid wr
On 12/5/14, 5:49 PM, Josh Berkus wrote:
On 12/05/2014 02:41 PM, Jim Nasby wrote:
Perhaps we should also officially recommend production servers be setup
to create core files. AFAIK the only downside is the time it would take
to write a core that's huge because of shared buffers, but perhaps
ther
On Fri, Dec 5, 2014 at 3:49 PM, Josh Berkus wrote:
> to enable core dumps on the production replicas because writing out the
> 16GB of shared buffers they had took over 10 minutes in a test.
No one ever thinks it'll happen to them anyway - recommending enabling
core dumps seems like a waste of ti
On 12/05/2014 02:41 PM, Jim Nasby wrote:
> Perhaps we should also officially recommend production servers be setup
> to create core files. AFAIK the only downside is the time it would take
> to write a core that's huge because of shared buffers, but perhaps
> there's some way to avoid writing those
Peter Geoghegan writes:
> On Fri, Dec 5, 2014 at 2:41 PM, Jim Nasby wrote:
>> Perhaps we should also officially recommend production servers be setup to
>> create core files. AFAIK the only downside is the time it would take to
>> write a core that's huge because of shared buffers
> I don't thin
On Fri, Dec 5, 2014 at 2:41 PM, Jim Nasby wrote:
> Perhaps we should also officially recommend production servers be setup to
> create core files. AFAIK the only downside is the time it would take to
> write a core that's huge because of shared buffers
I don't think that's every going to be pract
On 12/5/14, 4:11 PM, Peter Geoghegan wrote:
On Fri, Dec 5, 2014 at 1:29 PM, Josh Berkus wrote:
We made some changes which decreased query cancel (optimizing queries,
turning on hot_standby_feedback) and we haven't seen a segfault since
then. As far as the user is concerned, this solves the pro
On Fri, Dec 5, 2014 at 1:29 PM, Josh Berkus wrote:
>> We made some changes which decreased query cancel (optimizing queries,
>> turning on hot_standby_feedback) and we haven't seen a segfault since
>> then. As far as the user is concerned, this solves the problem, so I'm
>> never going to get a t
On 12/05/2014 12:54 PM, Josh Berkus wrote:
> Hackers,
>
> This is not a complete enough report for a diagnosis. I'm posting it
> here just in case someone else sees something like it, and having an
> additional report will help figure out the underlying issue.
>
> * 700GB database with around 5,
Hackers,
This is not a complete enough report for a diagnosis. I'm posting it
here just in case someone else sees something like it, and having an
additional report will help figure out the underlying issue.
* 700GB database with around 5,000 writes per second
* 8 replicas handling around 10,000
10 matches
Mail list logo
