Markus Wanner <markus@bluegap.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.
pgfoundry?
> 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.
-Kevin