Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on
Date
Msg-id 9837222c0907270201l4388b9edi445a61727d208b85@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on
List pgsql-hackers
On Sat, Jul 25, 2009 at 19:50, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> mha@postgresql.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 HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Non-blocking communication between a frontend and a backend (pqcomm)
Next
From: karpov@sao.ru (Sergey V. Karpov)
Date:
Subject: Re: improvements for dict_xsyn extended synonym dictionary - RRR