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

Re: CommitFest 2010-07 week one progress report

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Markus Wanner" <markus(at)bluegap(dot)ch>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CommitFest 2010-07 week one progress report
Date: 2010-07-23 15:46:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-rrreviewers
Markus Wanner <markus(at)bluegap(dot)ch> wrote:
> On 07/22/2010 08:51 PM, Robert Haas wrote:
>> It seems to me that the discussion is Alvaro and I are having
>> with Markus is tilted toward having Markus rewrite the imessages
>> interface to use an SLRU, in which case neither of them will go
>> in this CF. I'm hopeful that Heikki or Tom will comment on this
>> also when they get back from their vacations.
> Just for the record: I don't currently think a rewrite to use SLRU
> makes any sense for imessages.
>From the sidelines -- I don't know much about our SLRU
implementation, but on from what I have heard, it's hard to see that
as a good fit for what you're trying to do.  At a minimum, those
suggesting it should probably sketch out how that would work just a
little bit farther.
> But to answer Kevin's question: I don't expect to have the
> prerequisite patches committed this CF, as I don't think it
> currently makes any sense for Postgres to apply them.
OK, so all eight of these patches should be considered WIP
submissions.  That's good to know from a process management PoV.
> Nor did I feel there's general consensus that having we want to
> have a dynamic memory allocator (for shared memory).
On the other hand, I seem to remember hearing mentions of a desire
for that in the past, particularly regarding the ability to have
pluggable modules.  I suspect that any such feature would need to
allocate blocks from which space can be allocated and released in a
more lightweight manner than dealing with the OS -- probably with an
interface similar to current memory contexts.  How does the current
patch deal with that?
> It would be nice to be able to keep track of these kind of
> patches, which are available to Postgres and get maintained, but
> aren't currently needed or wanted.
> But do we want to use the CF application for that? How 
> do you prefer to proceed with these patches?
For WIP patches, I'm inclined to leave them open until the end of
the CF or until discussion seems to have hit an end.  I wonder if we
should have a flag in the application for these, so they show up in
the counts in a different way.
> It's also worth noting that Simon requested more and better 
> documentation. But I simply can't promise to write anything soon.
For a WIP patch, I suspect that putting on your personal TODO list,
to cover before any submission for acceptance, is the main thing. 
Of course, lack of comments or documentation may limit the feedback
you get for your WIP submission, as reverse-engineering intent from
code can be time-consuming and tedious.

In response to

pgsql-hackers by date

Next:From: Yeb HavingaDate: 2010-07-23 15:47:59
Subject: Re: Preliminary review of Synchronous Replication patches
Previous:From: Kris JurkaDate: 2010-07-23 15:35:53
Subject: Re: [HACKERS] Trouble with COPY IN

pgsql-rrreviewers by date

Next:From: David FetterDate: 2010-07-27 23:33:25
Subject: Review: Re: [PATCH] Re: [HACKERS] Adding xpath_exists function
Previous:From: Markus WannerDate: 2010-07-23 15:22:30
Subject: Re: [HACKERS] CommitFest 2010-07 week one progress report

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