Re: could not fork autovacuum worker process: No error

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(at)leadboat(dot)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.
> >