Hi,
The current approach could be better because we want to use it on
Windows/MacOS and other systems. So, I've tried to develop another
strategy - detaching shmem and DSM blocks before executing the abort()
routine.
As I can see, it helps and reduces the size of the core file.
--
regards,
A
On Wed, Feb 12, 2020, at 7:55 AM, tsunakawa.ta...@fujitsu.com wrote:
> From: Craig Ringer
>> Currently my options are "dump all shmem including shared_buffers" or
>> "dump no shmem". But I usually want "dump all shmem except
>> shared_buffers". It's tolerable to just dump s_b on a test system w
From: Craig Ringer
> Currently my options are "dump all shmem including shared_buffers" or
> "dump no shmem". But I usually want "dump all shmem except
> shared_buffers". It's tolerable to just dump s_b on a test system with
> a small s_b, but if enabling coredumps to track down some
> hard-to-rep
On Tue, 11 Feb 2020 at 03:07, Alexander Korotkov
wrote:
>
> Hi!
>
> In Postgres Pro we have complaints about too large core dumps. The
> possible way to reduce code dump size is to skip some information.
> Frequently shared buffers is most long memory segment in core dump.
> For sure, contents of
Hi,
On 2020-02-10 18:21:30 -0300, Alvaro Herrera wrote:
> On 2020-Feb-10, Andres Freund wrote:
>
> > Hi,
> >
> > On 2020-02-10 17:31:47 -0300, Alvaro Herrera wrote:
> > > Yeah. Maybe we should file bug reports against downstream packages to
> > > include a corefilter tweak.
> >
> > Hm, I'm not
On 2020-Feb-10, Andres Freund wrote:
> Hi,
>
> On 2020-02-10 17:31:47 -0300, Alvaro Herrera wrote:
> > Yeah. Maybe we should file bug reports against downstream packages to
> > include a corefilter tweak.
>
> Hm, I'm not sure that's a reasonable way to scale things. Nor am I
> really sure that'
Hi,
On 2020-02-10 17:31:47 -0300, Alvaro Herrera wrote:
> Yeah. Maybe we should file bug reports against downstream packages to
> include a corefilter tweak.
Hm, I'm not sure that's a reasonable way to scale things. Nor am I
really sure that's the right granularity.
> My development helper scr
On 2020-Feb-10, Andres Freund wrote:
> Have you considered postmaster (or even just the GUC processing in each
> process) adjusting /proc/self/coredump_filter instead?
>
> From the man page:
>
>The value in the file is a bit mask of memory mapping types (see
> mmap(2)). If a bit is s
Hi,
On 2020-02-10 22:07:13 +0300, Alexander Korotkov wrote:
> In Postgres Pro we have complaints about too large core dumps.
I've seen those too, and I've had them myself. It's pretty frustrating
if a core dump makes the machine unusable for half an hour while said
coredump is being written out..
Hi!
In Postgres Pro we have complaints about too large core dumps. The
possible way to reduce code dump size is to skip some information.
Frequently shared buffers is most long memory segment in core dump.
For sure, contents of shared buffers is required for discovering many
of bugs. But short c
10 matches
Mail list logo
