Prev: [HACKERS] reminder... beta4 is coming
Next: [HACKERS] non-overlapping, consecutive partitions
From: "Kevin Grittner" on 23 Jul 2010 11:46
Markus Wanner <markus(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Kevin Grittner" on 29 Jul 2010 11:46
New numbers on where we are with this CommitFest, as we approach the
half-way point:

72 patches were submitted
3 patches were withdrawn (deleted) by their authors
8 patches were moved to CommitFest 2010-09
--
61 patches in CommitFest 2010-07
--
3 committed to 9.0
--
58 patches for 9.1
--
1 rejected
13 returned with feedback
12 committed for 9.1
--
26 disposed
--
32 pending
10 ready for committer
--
22 will still need reviewer attention
7 waiting on author to respond to review
--
15 need review before further action
2 "Needs Review" patches don't have a reviewer assigned
--
13 patches need review and have a reviewer assigned

Of the eight patches moved to the next CF, all were moved by or at
the request of their authors. One was because the author didn't
feel the patch was ready for review and didn't have time to take
care of that in this CF. Six were WiP patches which need
documentation (perhaps a Wiki page) before others can effectively
review them. One is ready for committer, but isn't needed until we
are ready to commit the KNN-GiST, which was submitted for the next
CF.

13 of the 22 patches which will still need reviewer attention have
had at least one review. Many of the others have had discussion and
comment entries, but not yet a formal review.

The "WIP patch for serializable transactions with predicate locking"
by Dan Ports and myself has had some off-list questions from Joe
Conway. The questions are noted as opportunities for further code
comments. He pointed out one bug which has been fixed. And the
questions have caused me to notice a couple areas which need work to
reduce the false positive rate.

The last two patches which are without an assigned reviewer appear
to be in that state because there aren't many people who feel
competent to review these areas. The "ECPG FETCH readahead" patch
by Zolt�n B�sz�rm�nyi and the "WiP: Per-column collation" patch by
Peter Eisentraut both need *someone* to step up. Volunteers or
suggestions welcome.

Perhaps the biggest CF news of the last week is that we are no
longer faced with a fork in the efforts to implement synchronous
replication for 9.1 -- Zolt�n B�sz�rm�nyi has heroically offered to
withdraw his patch and work with Fujii Masao on enhancing the
subsequent "Another synchronous replication" patch. With everyone
working from the same base to push this effort forward, I'm hopeful
that we can overcome the challenges this technology presents. I
think it will be very good for the project if we can get a fairly
polished and "close to final" version committed before the last
CommitFest, so that it has a full alpha test cycle to settle in.
Note that this means that such a patch must be submitted within
*three and a half months*! Yes, we are that far in to the 9.1
development cycle.

Some of the other patches may have funny dates, but I believe from
off-list emails that things are generally moving OK.

-Kevin


"Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> wrote:

> 71 patches were submitted
> 3 patches were withdrawn (deleted) by their authors
> --
> 68 total patches currently in the application
> --
> 3 committed to 9.0
> --
> 65 9.1 patches
> --
> 1 rejected
> 5 returned with feedback
> 11 committed for 9.1
> --
> 17 9.1 patches disposed
> --
> 48 pending
> 8 ready for committer
> --
> 40 will still need reviewer attention
> 9 waiting on author to respond to review
> --
> 31 need review before further action
> 13 "Needs Review" patches don't have a reviewer assigned
> --
> 18 patches have reviews due within four days or less


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: [HACKERS] reminder... beta4 is coming
Next: [HACKERS] non-overlapping, consecutive partitions