Re: InitProcGlobal cleanup - Mailing list pgsql-hackers

From Robert Haas
Subject Re: InitProcGlobal cleanup
Date
Msg-id BANLkTin6=rQ3tM6qLNvTuGDCpG9ROgLaPw@mail.gmail.com
Whole thread Raw
In response to Re: InitProcGlobal cleanup  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: InitProcGlobal cleanup
List pgsql-hackers
On Thu, Jun 2, 2011 at 1:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> While working on my patch to reduce the overhead of frequent table
>> locks, I had cause to monkey with InitProcGlobal() and noticed that
>> it's sort of a mess.  For reasons that are not clear to me, it
>> allocates one of the three PGPROC arrays using ShemInitStruct() and
>> the other two using ShmemAlloc().  I'm not clear on why we should use
>> different functions for different allocations, and it also seems like
>> it would make sense to do the whole allocation at once instead of
>> doing three separate ones.  Also, the setup of AuxiliaryProcs is
>> strangely split into two parts, one at the top of the function (where
>> we allocate the memory) and the other at the bottom (where we
>> initialize it), but there's no clear reason to break it up like that.
>
>> Any reason not to instead do something like the attached?
>
> I find this a whole lot less readable, because you've largely obscured
> the fact that there are three or four different groups of PGPROC
> structures being built here and then linked into several different
> lists/arrays.  The code might be okay but it desperately needs more
> comments.

OK, here's a version with more comments.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: storing TZ along timestamps
Next
From: Greg Stark
Date:
Subject: Re: patch review : Add ability to constrain backend temporary file space