On 2017-02-06 16:06:25 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-02-06 15:39:10 -0500, Peter Eisentraut wrote:
> >> On 2/6/17 6:28 AM, Konstantin Knizhnik wrote:
> >>> I wonder why do we prohibit now configuration of Postgres without mmap?
>
> >> It's not
Andres Freund writes:
> On 2017-02-06 15:39:10 -0500, Peter Eisentraut wrote:
>> On 2/6/17 6:28 AM, Konstantin Knizhnik wrote:
>>> I wonder why do we prohibit now configuration of Postgres without mmap?
>> It's not really prohibited, but it's not something that people
On 2017-02-06 15:39:10 -0500, Peter Eisentraut wrote:
> On 2/6/17 6:28 AM, Konstantin Knizhnik wrote:
> > I wonder why do we prohibit now configuration of Postgres without mmap?
>
> It's not really prohibited, but it's not something that people generally
> need, and we want to keep the number of
On 2/6/17 6:28 AM, Konstantin Knizhnik wrote:
> I wonder why do we prohibit now configuration of Postgres without mmap?
It's not really prohibited, but it's not something that people generally
need, and we want to keep the number of configuration variations low.
--
Peter Eisentraut
I tried to rebuild Postgres without mmap and the problem disappears
(pgbench with -C doesn't cause connection limit exhaustion any more).
Unfortunately there is no any convenient way to configure PostgreSQL not
to use mmap.
I have to edit sysv_shmem.c file, commenting
#ifndef EXEC_BACKEND
Last update on the problem.
Using kdb tool (thank's to Tony Reix for advice and help) we get the
following trace of Poastgres backend in existing stack trace:
pvthread+073000 STACK:
[005E1958]slock+000578 (005E1958, 80001032 [??])
[9558].simple_lock+58 ()
On 24.01.2017 18:26, Tom Lane wrote:
Konstantin Knizhnik writes:
But ps shows that status of process is
[14:46:02]root@postgres:~ # ps -elk | grep 25691556
* A - 25691556 - - - - -
As far as I could find by googling, this means that the process is
not
Konstantin Knizhnik writes:
> But ps shows that status of process is
> [14:46:02]root@postgres:~ # ps -elk | grep 25691556
> * A - 25691556 - - - - -
As far as I could find by googling, this means that the process is
not actually a zombie yet, so it's not the
Hi hackers,
Yet another story about AIX. For some reasons AIX very slowly cleaning
zombie processes.
If we launch pgbench with -C parameter then very soon limit for maximal
number of connections is exhausted.
If maximal number of connection is set to 1000, then after ten seconds
of pgbench