Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on
Date: 2009-07-27 09:01:44
Message-ID: 9837222c0907270201l4388b9edi445a61727d208b85@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Sat, Jul 25, 2009 at 19:50, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> mha(at)postgresql(dot)org (Magnus Hagander) writes:
>> Log Message:
>> -----------
>> Reserve the shared memory region during backend startup on Windows, so
>> that memory allocated by starting third party DLLs doesn't end up
>> conflicting with it.
>
> I am wondering why failure of the various TerminateProcess calls in
> postmaster.c is elog(ERROR) and not elog(LOG).  While that probably
> shouldn't happen, aborting the postmaster isn't a good response if it
> does.  This patch introduces a new occurrence, but I see it is just
> copying what was there already.

The case where it's doing it now is really a "can't happen" place, so
I don't think it's a big issue there. It could be argued that if we
can't terminate a process we just created (but never even started!),
something is very very badly broken on the system and we might as well
give up. Same for the part where we fail to ResumeThread() on the main
thread of a new process.

However, it seems that for example the one at line 3629 - where we're
just failing to save our backend state - shouldn't be such a FATAL
error. But if you actually look up into the function
save_backend_variables(), it's actually hardcoded to return true... In
case something goes wrong in there, there's an actual ereport(ERROR)
happening deep down already
(write_inheritable_socket/write_duplicated_handle).

To fix that we'd just have to turn those functions all into returning
boolean and log with LOG instead. AFAIK, we've had zero reports of
this actually happening, so I'm not sure it's worth redesigning.
Thoughts?

-- 
 Magnus Hagander
 Self: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

pgsql-hackers by date

Next:From: Sergey V. KarpovDate: 2009-07-27 10:01:46
Subject: Re: improvements for dict_xsyn extended synonym dictionary - RRR
Previous:From: Fujii MasaoDate: 2009-07-27 08:55:44
Subject: Re: Non-blocking communication between a frontend and a backend (pqcomm)

pgsql-committers by date

Next:From: Tom LaneDate: 2009-07-27 14:14:52
Subject: Re: Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on
Previous:From: Magnus HaganderDate: 2009-07-27 08:46:10
Subject: pgsql: Fix minor memory leak in Win32 SID handling functions.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group