could not fork autovacuum worker process: No error

Tomasz Szypowski <tomasz.szypowski@gmail.com> writes:

Hi PostgreSQL Team,
since last month we receive error as in the topic. After restart one can
work with server but not for long.

Is it connected with one of Windows Update on Server 2012 (or Windows 10)
ASLR?

If this is on Windows, there's probably more information about the
failure in the postmaster log --- look for LOG messages just before
the "fork failure" complaint.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hi Tom,

is a greate honour for me to meet you personally.
Thanks for the quick response as well.
I send you logs

regards
Thomas

2017-01-25 16:33 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:

is a greate honour for me to meet you personally.
Thanks for the quick response as well.
Here is the log for autovaccum, but it doesn`t work with normal login as
well:
2016-11-16 08:57:03 CET LOG: could not reserve shared memory region
(addr=015E0000) for child 000012D4: error code 487
2016-11-16 08:57:03 CET LOG: could not fork autovacuum worker process: No
error

regards
Thomas

2017-01-25 16:33 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:

Tomasz Szypowski <tomasz.szypowski@gmail.com> writes:

I send you logs

Hmm ....

2016-11-10 17:58:42 CET LOG: could not reserve shared memory region (addr=015E0000) for child 0000085C: error code 487
2016-11-10 17:58:42 CET LOG: could not fork autovacuum worker process: No error
2016-11-10 17:58:43 CET LOG: could not reserve shared memory region (addr=015E0000) for child 00000828: error code 487
2016-11-10 17:58:43 CET LOG: could not fork autovacuum worker process: No error
2016-11-10 17:58:44 CET LOG: could not reserve shared memory region (addr=015E0000) for child 0000085C: error code 487
2016-11-10 17:58:44 CET LOG: could not fork autovacuum worker process: No error
2016-11-10 17:59:02 CET LOG: could not reserve shared memory region (addr=015E0000) for child 00000878: error code 487
2016-11-10 17:59:02 CET LOG: could not fork autovacuum worker process: No error
2016-11-10 17:59:03 CET LOG: could not reserve shared memory region (addr=015E0000) for child 00000874: error code 487
2016-11-10 17:59:03 CET LOG: could not fork autovacuum worker process: No error
2016-11-10 17:59:04 CET LOG: could not reserve shared memory region (addr=015E0000) for child 00000878: error code 487
2016-11-10 17:59:04 CET LOG: could not fork autovacuum worker process: No error

Yeah, that probably is an ASLR problem :-(. We don't have a good
solution for that on Windows yet.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Tom,

what do you suggest? Disabling ASLR? Do you know approx. how long will it
take for you to implement the change?

regards
Thomas

2017-01-25 17:04 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:

Tomasz Szypowski <tomasz.szypowski@gmail.com> writes:

what do you suggest? Disabling ASLR?

Yes.

Do you know approx. how long will it
take for you to implement the change?

There's no plan for how to solve this, so I dunno.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Wed, Jan 25, 2017 at 05:16:52PM +0100, Tomasz Szypowski wrote:

what do you suggest? Disabling ASLR? Do you know approx. how long will it
take for you to implement the change?

We thought we implemented it years ago:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f3e17b4827b61ad84e0774e3e43da4c57c4487f

On Wed, Jan 25, 2017 at 01:46:01PM +0100, Tomasz Szypowski wrote:

We use PostgreSQL 9.5.5 and 9.5.4. Both compiled from sources.

Which compiler and compiler version did you use? What is the content of your
config.pl or your ./configure command line?

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Sat, Apr 1, 2017 at 11:41 AM, Noah Misch <noah@leadboat.com> wrote:

On Wed, Jan 25, 2017 at 05:16:52PM +0100, Tomasz Szypowski wrote:

what do you suggest? Disabling ASLR? Do you know approx. how long will it
take for you to implement the change?

Last November I saw a high resurgence of such reports after a Windows
update. The builds in question had ASLR enabled and disabling it made
the trick but the update visibly made the failures more easier to show
up.

We thought we implemented it years ago:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f3e17b4827b61ad84e0774e3e43da4c57c4487f

I think that the OP here is asking for a solution where our shared
memory implementation is not messed up with ASLR enabled. And we don't
have a clear solution for that yet.

On Wed, Jan 25, 2017 at 01:46:01PM +0100, Tomasz Szypowski wrote:

We use PostgreSQL 9.5.5 and 9.5.4. Both compiled from sources.

Which compiler and compiler version did you use? What is the content of your
config.pl or your ./configure command line?

Likely there are custom options used here, it may be good to look with
dumpbin what's the state of the builds.
--
Michael

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Michael Paquier <michael.paquier@gmail.com> writes:

I think that the OP here is asking for a solution where our shared
memory implementation is not messed up with ASLR enabled. And we don't
have a clear solution for that yet.

Yeah. I don't know anything about the address space layout under Windows,
but it occurs to me to ask how much of the address space their version of
ASLR thinks it can chew up. Maybe we could fix this by explicitly asking
for the shmem block to be mapped at the top of memory always, or something
along that line. Perhaps it would only be fixable that way under Win64,
but that would still be a good step forward.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hello guys,

I build PostgreSQL 32 bit on Windows with Microsoft Visual Studio 8.
I don`t see any config.pl file, Do you mean config_default.pl? If yes, than
the only module, that I activiate is zlib. I don`t need any extension like
openssl, xml and so on.

Regards
Thomas

2017-04-02 17:58 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:

On Sun, Apr 02, 2017 at 07:51:59PM +0200, Tomasz Szypowski wrote:

I build PostgreSQL 32 bit on Windows with Microsoft Visual Studio 8.

That version number is ambiguous. From the command prompt in which you build
PostgreSQL, what is the output of these two commands?

cl
systeminfo | findstr /B OS

If you build PostgreSQL on one system and run it on a different system, what
is the output of "systeminfo | findstr /B OS" on the runtime system?

I don`t see any config.pl file, Do you mean config_default.pl?

Technically no. If you have not created a config.pl, that is fine.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Sun, Apr 02, 2017 at 06:08:56PM -0400, Noah Misch wrote:

On Sun, Apr 02, 2017 at 07:51:59PM +0200, Tomasz Szypowski wrote:

I build PostgreSQL 32 bit on Windows with Microsoft Visual Studio 8.

That version number is ambiguous. From the command prompt in which you build
PostgreSQL, what is the output of these two commands?

cl
systeminfo | findstr /B OS

If you build PostgreSQL on one system and run it on a different system, what
is the output of "systeminfo | findstr /B OS" on the runtime system?

Also, could you run a test workload that reproduces the problem against a
postgres.exe built with the attached patch? This will dump details of your
memory postgres.exe memory map to the log, hopefully giving a clue about the
source of the trouble.

Hi, here is the result of OS:

OS Name: Microsoft Windows Server 2012 R2 Standard
OS Version: 6.3.9600 N/A Build 9600
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Server
OS Build Type: Multiprocessor Free

Here is the result of cl:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for
80x86
Copyright (C) Microsoft Corporation. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

and of OS:
OS Name: Microsoft Windows 10 Pro

OS Version: 10.0.10586 N/A Build 10586
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Workstation
OS Build Type: Multiprocessor Free

pozdrawiam
Tomek

2017-04-03 8:51 GMT+02:00 Noah Misch <noah@leadboat.com>:

Thanks. Would you reproduce the problem after applying the patch I provided,
then capture the logs?

On Mon, Apr 03, 2017 at 07:18:40PM +0200, Tomasz Szypowski wrote:

Hi, here is the result of OS:

OS Name: Microsoft Windows Server 2012 R2 Standard
OS Version: 6.3.9600 N/A Build 9600
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Server
OS Build Type: Multiprocessor Free

Here is the result of cl:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for
80x86
Copyright (C) Microsoft Corporation. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

and of OS:
OS Name: Microsoft Windows 10 Pro

OS Version: 10.0.10586 N/A Build 10586
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Workstation
OS Build Type: Multiprocessor Free

pozdrawiam
Tomek

2017-04-03 8:51 GMT+02:00 Noah Misch <noah@leadboat.com>:

On Sun, Apr 02, 2017 at 06:08:56PM -0400, Noah Misch wrote:

On Sun, Apr 02, 2017 at 07:51:59PM +0200, Tomasz Szypowski wrote:

I build PostgreSQL 32 bit on Windows with Microsoft Visual Studio 8.

That version number is ambiguous. From the command prompt in which you

build

PostgreSQL, what is the output of these two commands?

cl
systeminfo | findstr /B OS

If you build PostgreSQL on one system and run it on a different system,

what

is the output of "systeminfo | findstr /B OS" on the runtime system?

Also, could you run a test workload that reproduces the problem against a
postgres.exe built with the attached patch? This will dump details of your
memory postgres.exe memory map to the log, hopefully giving a clue about
the
source of the trouble.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

unfortunatellly this error is not deterministic one, if I know any news, I
will inform you immediatelly

regards
Thomas

2017-04-18 4:59 GMT+02:00 Noah Misch <noah@leadboat.com>: