On 09/20/2014 06:54 AM, Michael Paquier wrote:
CF3 is actually over for a couple of days,
There are different opinions on when a commitfest is "over". In my
opinion, the point of a commitfest is that every patch that someone
submits gets enough review so that the patch author knows what he ne
CF3 is actually over for a couple of days, wouldn't it be better to
bounce back patches marked as "waiting on author" and work on the rest
needing review?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
Hi,
I've update my entry.
[rounding up time value less than its unit]
https://commitfest.postgresql.org/action/patch_view?id=1507
regards,
-
Tomonari Katsumata
(2014/09/12 7:03), Tomas Vondra wrote:
> On 11.9.2014 21:14, Petr Jelinek wrote:
>> On 11/09/14 18:59, Tomas Vondra wro
On 11.9.2014 21:14, Petr Jelinek wrote:
> On 11/09/14 18:59, Tomas Vondra wrote:
>> On 10.9.2014 22:39, Heikki Linnakangas wrote:
>>> The bad news is that the rest don't seem to moving graduating from the
>>> Needs Review state.
>>
>> ISTM that many patches
>>
>> (b) in 'waiting on author' are not
On 11/09/14 18:59, Tomas Vondra wrote:
On 10.9.2014 22:39, Heikki Linnakangas wrote:
The bad news is that the rest don't seem to moving graduating from the
Needs Review state.
ISTM that many patches
(b) in 'waiting on author' are not really waiting, because the author
already responded /
On 10.9.2014 22:39, Heikki Linnakangas wrote:
> The bad news is that the rest don't seem to moving graduating from the
> Needs Review state.
ISTM that many patches
(a) in 'needs review' actually have a review, or are being thoroughly
discussed
(b) in 'waiting on author' are not really waitin
Another commitfest week has passed, and here are still. There are now 24
patches in "Needs Review" state, and 8 in "Ready for Committer". I'm not
paying attention to the "Waiting on Author" patches - once we're close
to zero on the other patches, those will be bounced back.
The good news is th
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> > > 5. Better syntax for REINDEX
>
> > > I think the latter 3 patches are missing a reviewer because no-one
> > > is interested in them. There was some discussion o
Stephen Frost wrote:
> * Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> > 5. Better syntax for REINDEX
> > I think the latter 3 patches are missing a reviewer because no-one
> > is interested in them. There was some discussion on the REINDEX
> > syntax, and whether we want the patch at all.
On Thu, Sep 4, 2014 at 12:42 PM, Stephen Frost wrote:
> I'm certainly interested in the pgcrypto patches and can look at REINDEX
> this weekend.
I'm thinking of picking one of these up, but I'll be on vacation next
week, and so probably won't get to it until the 15th at the earliest.
The hash joi
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> 5. Better syntax for REINDEX
> 6. pgcrypto: support PGP signatures
> 7. pgcrypto: PGP armour headers
[...]
> I think the latter 3 patches are missing a reviewer because no-one
> is interested in them. There was some discussion on the REINDEX
Hi
2014-09-03 13:18 GMT+02:00 Heikki Linnakangas :
> We now have 32 patches in "Needs Review" state, and 7 of those don't have
> a reviewer assigned. They are:
>
> 1. Grouping Sets
I plan to do review of Grouping Sets, but I am afraid so I cannot to do in
next two weeks.
Regards
Pavel
> 2.
We now have 32 patches in "Needs Review" state, and 7 of those don't
have a reviewer assigned. They are:
1. Grouping Sets
2. hash join - dynamic bucket count
3. Enable WAL archiving even in standby
4. Selectivity estimation for inet operators
5. Better syntax for REINDEX
6. pgcrypto: support PGP
The first week of the commitfest is now behind us.
There are still 15 patches in "Needs Review" state, with no reviewer
assigned. Please pick a patch and review!
There are 20 patches in "Needs Review" state, with a reviewer assigned.
If you have signed up as the reviewer, please proceed with
On Thu, Jul 31, 2014 at 1:36 PM, Abhijit Menon-Sen
wrote:
> At 2014-07-30 13:27:24 -0400, robertmh...@gmail.com wrote:
> > Is anybody working on closing out the "in progress" CommitFest?
>
> Yes. I was away for a few days, but I'm back at work now and will move
> the patches.
Okay. It makes sens
At 2014-07-30 13:27:24 -0400, robertmh...@gmail.com wrote:
>
> Hi,
>
> Is anybody working on closing out the "in progress" CommitFest?
Yes. I was away for a few days, but I'm back at work now and will move
the patches.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On Thu, Jul 31, 2014 at 3:45 PM, Amit Kapila wrote:
> In past, I have seen that we try to make sure that each patch
> gets atleast one review in CF, so do you think we should try
> that this time as well (I think patches which don't have even one
> review are not too many). To be honest, I don't
On Wed, Jul 30, 2014 at 10:57 PM, Robert Haas wrote:
>
> Hi,
>
> Is anybody working on closing out the "in progress" CommitFest?
>
> https://commitfest.postgresql.org/action/commitfest_view?id=22
If you or others don't have any objection, then I will do this on
coming weekend.
> I think anything
Hi,
Is anybody working on closing out the "in progress" CommitFest?
https://commitfest.postgresql.org/action/commitfest_view?id=22
I think anything that is "waiting on author" should certainly be
bounced at this point, and stuff that never got reviewed or is ready
for committer should probably b
On Thu, 2011-07-21 at 00:21 +0200, Florian Pflug wrote:
> There's a small additional concern, though, which is that there's an
> XPath 2.0 spec out there, and it modifies the type system and data model
> rather heavily. So before we go adding functions, it'd probably be wise
> to check that we're n
Florian Pflug writes:
> There's a small additional concern, though, which is that there's an
> XPath 2.0 spec out there, and it modifies the type system and data model
> rather heavily. So before we go adding functions, it'd probably be wise
> to check that we're not painting ourselves into a corn
On Jul20, 2011, at 23:35 , Tom Lane wrote:
> I find your argument against XPATH_STRING() a bit unconvincing.
> The use case for that is not where you are trying to evaluate an
> unknown, arbitrary XPath expression; it's where you are evaluating an
> expression that you *know* returns string (ie, it
[ having now read the relevant threads a bit more carefully ... ]
Florian Pflug writes:
> On Jul18, 2011, at 22:19 , Tom Lane wrote:
>> Yeah, it's not clear to me either which of those are still reasonable
>> candidates for committing as-is.
> There are actually three XML-related patches from me
Excerpts from Tom Lane's message of mar jul 19 12:09:24 -0400 2011:
> Robert Haas writes:
> > On Mon, Jul 18, 2011 at 4:19 PM, Tom Lane wrote:
> >> If you mean the business about allowing GUCs in postgresql.conf to be
> >> applied even if there are semantic errors elsewhere, I'm just as happy
> >
Robert Haas writes:
> On Mon, Jul 18, 2011 at 4:19 PM, Tom Lane wrote:
>> If you mean the business about allowing GUCs in postgresql.conf to be
>> applied even if there are semantic errors elsewhere, I'm just as happy
>> to let Alexey or Florian have a go at it first, if they want. The real
>> q
On 2011-07-18 21:59, Robert Haas wrote:
There are only two patches left and I think we really ought to try to
take a crack at doing something with them. Yeb is working on the
userspace access vector cache patch, which I think is going drag on
longer than we want keep the CommitFest open, but I'm
On Mon, 2011-07-18 at 15:59 -0400, Robert Haas wrote:
> On a pgbench run with 8
> clients on a 32-core machine, I see about a 2% speedup from that patch
> on pgbench -S, and it grows to 8% at 32 clients. At 80 clients (but
> still just a 32-core box), the results bounce around more, but taking
> t
On Jul18, 2011, at 22:19 , Tom Lane wrote:
>> and an
>> error-reporting patch that Tom weighed in on over the weekend. This
>> last suffers from the issue that it's not quite clear whether Tom is
>> going to do the work or whether he's expecting the submitter to do it.
>
> If you mean the busines
On Jul18, 2011, at 22:19 , Tom Lane wrote:
> Robert Haas writes:
>> We're down to three patches that fall into this category: two XML
>> patches by Florian, which have been somewhat derailed by an argument
>> about whether values of type xml should, in fact, be required to be
>> valid xml (I think
On Mon, Jul 18, 2011 at 4:19 PM, Tom Lane wrote:
>> and an
>> error-reporting patch that Tom weighed in on over the weekend. This
>> last suffers from the issue that it's not quite clear whether Tom is
>> going to do the work or whether he's expecting the submitter to do it.
>
> If you mean the b
Robert,
>> * Collect frequency statistics and selectivity estimation for arrays
>> * Allow multiple Postgres clusters running on the same machine to
>> distinguish themselves in the event log
>> * lazy vxid locks
>
> I'm not clear on your criteria for moving these patches, as they seem
> to be in
Simon,
>> * Cascade Replication
>
> Sorry, too busy reviewing to take note of this. I expect to commit
> when its tested and ready.
So, would that be this commitfest, or next commitfest?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsq
Robert Haas writes:
> We're down to three patches that fall into this category: two XML
> patches by Florian, which have been somewhat derailed by an argument
> about whether values of type xml should, in fact, be required to be
> valid xml (I think you know my vote on this one...);
Yeah, it's no
On Fri, Jul 15, 2011 at 10:05 PM, Josh Berkus wrote:
> PATCHES WHICH HAVE BEEN UPDATED AND NEED FURTHER REVIEW:
>
> * Cascade Replication
Sorry, too busy reviewing to take note of this. I expect to commit
when its tested and ready.
--
Simon Riggs http://www.2ndQuadrant.com/
On Fri, Jul 15, 2011 at 5:05 PM, Josh Berkus wrote:
> As you can probably tell, we are not ready to end the commitfest. (I
> think Robert gave me this CF to show why even talking about a one-week
> mini-fest is a fantasy. If so, successful.).
Heh, heh. Well, it wasn't that premeditated, but I'
On Jul15, 2011, at 23:05 , Josh Berkus wrote:
> * Bugfix for XPATH() if expression returns a scalar value
Well, Peter Eisentraut seemed to disagree with my approach initially,
and seemed to prefer a separate function for XPATH expressions which
return a scalar value.
http://archives.postgresql.
All,
As you can probably tell, we are not ready to end the commitfest. (I
think Robert gave me this CF to show why even talking about a one-week
mini-fest is a fantasy. If so, successful.).
I've booted the patches which obviously aren't going to be immediately
ready. Nine patches are ready for
Tom Lane wrote:
I wrote:
Robert Haas writes:
* Fix large object support in pg_dump. I think this is just waiting
for a second opinion on whether the approach is correct. I've been
meaning to look at it, but haven't gotten enough round tuits; maybe
someone else would like to take a
I wrote:
> Robert Haas writes:
>> * Fix large object support in pg_dump. I think this is just waiting
>> for a second opinion on whether the approach is correct. I've been
>> meaning to look at it, but haven't gotten enough round tuits; maybe
>> someone else would like to take a look? This is a
On Wed, Feb 17, 2010 at 6:39 AM, Tom Lane wrote:
>> * Faster CREATE DATABASE by delaying fsync. This is really two
>> patches now, one of which is apparently to be backpatched.
>
> This one (both parts) seems to have crashed and burned on unexpected
> portability issues :-(. Do we have any expec
On Tue, Feb 16, 2010 at 05:22:27PM -0500, Robert Haas wrote:
> > It's certainly been an interesting introduction to PostgreSQL
> > development!
>
> Hopefully we haven't scared you off - your work is definitely very
> much appreciated (and I at least hope to see you back for 9.1)!
Thanks Robert. T
On Wednesday 17 February 2010 07:39:16 Tom Lane wrote:
> Robert Haas writes:
> > * Fix large object support in pg_dump. I think this is just waiting
> > for a second opinion on whether the approach is correct. I've been
> > meaning to look at it, but haven't gotten enough round tuits; maybe
> >
On Tue, Feb 16, 2010 at 02:25:00PM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 2:19 PM, Tim Bunce wrote:
>
> > p.s. One quick heads-up: David Wheeler has reported a possible issue
> > with Safe 2.21. I hope to investigate that tomorrow.
>
> Actually it's 2.22. 2.21 is already dead.
Oops
Robert Haas writes:
> * Fix large object support in pg_dump. I think this is just waiting
> for a second opinion on whether the approach is correct. I've been
> meaning to look at it, but haven't gotten enough round tuits; maybe
> someone else would like to take a look? This is an open item, so
> It's certainly been an interesting introduction to PostgreSQL
> development!
Hopefully we haven't scared you off - your work is definitely very
much appreciated (and I at least hope to see you back for 9.1)!
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
On Feb 16, 2010, at 2:19 PM, Tim Bunce wrote:
> It's certainly been an interesting introduction to PostgreSQL development!
"Interesting," eh? Look forward to your blog post about the experience. ;-P
> Tim.
>
> p.s. One quick heads-up: David Wheeler has reported a possible issue
> with Safe 2.21
On Tue, Feb 16, 2010 at 04:42:29PM -0500, Andrew Dunstan wrote:
> Tim Bunce wrote:
> >On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote:
> >>Robert Haas wrote:
> >>>We're down to 5 patches remaining, and 1 day remaining, so it's time
> >>>to try to wrap things up.
> >>>
> >>>* Package
Tim Bunce wrote:
On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote:
Robert Haas wrote:
We're down to 5 patches remaining, and 1 day remaining, so it's time
to try to wrap things up.
* Package namespace and Safe init cleanup for plperl. Andrew Dunstan
is taking care of t
Tom Lane wrote:
> Robert Haas writes:
> > * Listen / Notify rewrite. This is the only one of the remaining
> > patches that is not marked as Ready for Committer, but I think it
> > would be good if someone (probably Tom) at least took a look at it.
> > I'm not sure if it's committable at this poi
(2010/02/14 13:34), Robert Haas wrote:
> * Fix large object support in pg_dump. I think this is just waiting
> for a second opinion on whether the approach is correct. I've been
> meaning to look at it, but haven't gotten enough round tuits; maybe
> someone else would like to take a look? This i
On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote:
>
> Robert Haas wrote:
> >We're down to 5 patches remaining, and 1 day remaining, so it's time
> >to try to wrap things up.
> >
> >* Package namespace and Safe init cleanup for plperl. Andrew Dunstan
> >is taking care of this one, I
Robert Haas wrote:
We're down to 5 patches remaining, and 1 day remaining, so it's time
to try to wrap things up.
* Package namespace and Safe init cleanup for plperl. Andrew Dunstan
is taking care of this one, I believe.
I will get this in, with changes as discussed recently.
I also
> I will look at this one. It'd be nice to get it in if at all possible,
> because the existing listen/notify infrastructure won't play very nicely
> with HS --- eg, inspecting pg_listener on the slave might yield the
> false impression that some of the slave-side backends had active LISTENs
> be
Robert Haas writes:
> * Listen / Notify rewrite. This is the only one of the remaining
> patches that is not marked as Ready for Committer, but I think it
> would be good if someone (probably Tom) at least took a look at it.
> I'm not sure if it's committable at this point, but we should at least
We're down to 5 patches remaining, and 1 day remaining, so it's time
to try to wrap things up.
* Fix large object support in pg_dump. I think this is just waiting
for a second opinion on whether the approach is correct. I've been
meaning to look at it, but haven't gotten enough round tuits; mayb
Hi,
Boszormenyi Zoltan írta:
> Greg Smith írta:
>
>> 4) Investigate and be explicit about the potential breakage here both
>> for libpq clients and at least one additional driver too. If I saw a
>> demonstration that this didn't break the JDBC driver, for example, I'd
>> feel a lot better abou
Robert Haas wrote:
Here's an overview of where we stand with the remaining 14 patches,
according to my best understanding of the situation.
* rbtree - I have done a lot of work reviewing this, and Mark
Cave-Ayland has done some work on it, too. But there are some
unanswered performance quest
Here's an overview of where we stand with the remaining 14 patches,
according to my best understanding of the situation.
* Fix large object support in pg_dump - I haven't looked at this, but
it seems like it's relatively close to being ready for commit. We
need to get this one done as it is a rel
On Wed, Jan 27, 2010 at 4:05 PM, Robert Haas wrote:
> Waiting for Re-Review (5)
> =
> Writeable CTEs
Set this ready for commit. For such a small patch, it's a wonderful
feature. I think it deserves a fair shot on this 'fest.
insert/returning/subquery is far and away one of
Robert Haas escribió:
> Furthermore, if we are going to ever change this in an incompatible
> way that may break clients, isn't 9.0 exactly the right time to do
> that? If that doesn't scream "big changes coming, proceed with
> caution", I don't know what would.
I agree with this -- if we're eve
On Wed, Jan 27, 2010 at 11:13 PM, Greg Smith wrote:
> Robert Haas wrote:
>> plpython3 - no reviewer yet
>
> This whole feature seems quite interesting, and I'm really impressed at how
> much work James has put into rethinking what a Python PL should look like.
> But isn't the fact that there isn'
Hi,
Greg Smith írta:
>> Provide rowcount for utility SELECTs
>
> I think I can write a review for this one right now based on the
> discussion that's already happened:
>
> -Multiple people think the feature is valuable and it seems worth
> exploring
> -The right way to handle the protocol change h
Robert Haas wrote:
Waiting for Initial Review (4)
==
plpython3 - no reviewer yet
This whole feature seems quite interesting, and I'm really impressed at
how much work James has put into rethinking what a Python PL should look
like. But isn't the fact that there isn
Robert Haas wrote:
Some of the perl patches
have not yet been reviewed either, but I'm a little less concerned
about those because it seems that Andrew is working on those anyway:
still, if anyone feels inclined to volunteer, I believe Andrew has
said he would appreciate another pair of eyes.
We have 20 remaining patches to deal with for the 2010-01 CommitFest.
I've attempted to break down the status of these patches below. The
good news is that almost half of the remaining patches are either
already marked as Ready for Committer, or have already been reviewed
once and will likely be m
Robert Haas wrote:
I'm happy with Andrew's interpretation --- I just want a separate text
field for inserting a committer's name. I don't want any magic behavior
of that field.
OK, I'll add a separate text field for the committer's name, but for
now it won't display on the summary page
On Tue, Dec 1, 2009 at 9:43 AM, Robert Haas wrote:
> On Tue, Dec 1, 2009 at 9:42 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> If we went with Bruce's interpretation, we could have a "committer"
>>> field that only appears when the status is "Claimed by Committer" or
>>> "Committed" and the con
Robert Haas wrote:
OK, I'll add a separate text field for the committer's name, but for
now it won't display on the summary page, just the detail page.
Perhaps it could go underneath the reviewer names, maybe in a different
color. (And yes, like many of us I suck at GUI design, so feel
BTW, if you have time for any purely cosmetic details ... the way the
CommitFest field on a patch detail page works has always struck me as
weird. It's a data field, and so if it has any behavior at all that
behavior ought to involve modifying its value. But what it actually is
is a navigation li
On Tue, Dec 1, 2009 at 9:42 AM, Tom Lane wrote:
> Robert Haas writes:
>> If we went with Bruce's interpretation, we could have a "committer"
>> field that only appears when the status is "Claimed by Committer" or
>> "Committed" and the contents of that field could be displayed in
>> parentheses i
Robert Haas writes:
> If we went with Bruce's interpretation, we could have a "committer"
> field that only appears when the status is "Claimed by Committer" or
> "Committed" and the contents of that field could be displayed in
> parentheses in the status column, like this: Claimed by Committer (T
Robert Haas writes:
> On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane wrote:
>> Robert acknowledged the need for a "claimed by committer" field in the
>> fest application, but he hasn't got round to it yet.
> Sorry I haven't gotten around to this. Beyond being a little burned
> out a little bit, I h
On Tue, Dec 1, 2009 at 8:27 AM, Andrew Dunstan wrote:
> Bruce Momjian wrote:
>>>
>>> It would also like to clarify the use case for this a little bit more.
>>> Is this just to track patches which committers are in the process of
>>> committing (or have committed)? Or would a committer potentiall
Bruce Momjian wrote:
It would also like to clarify the use case for this a little bit more.
Is this just to track patches which committers are in the process of
committing (or have committed)? Or would a committer potentially set
this on some patch that was still being reviewed, and if so wou
Robert Haas wrote:
> On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> As I have observed before, I think we need some infrastructure to help
> >> committers claim items, so we don't duplicate work.
> >
> > Robert acknowledged the need for a "claimed by committer"
On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> As I have observed before, I think we need some infrastructure to help
>> committers claim items, so we don't duplicate work.
>
> Robert acknowledged the need for a "claimed by committer" field in the
> fest application
On Mon, Nov 30, 2009 at 10:16 PM, Greg Smith wrote:
> Considering that one of those was a holiday week with a lot of schedule
> disruption proceeding it, I don't know how much faster things could have
> moved. There were large chunks of the reviewer volunteers who wanted only
> jobs they could fi
Tom Lane wrote:
I'm going to look at the YAML format for EXPLAIN patch shortly.
Do we have consensus yet that we want YAML? It seemed, well,
yet another format without all that much advantage over what's
there.
I think you and I are the two main skeptics ;
On Nov 30, 2009, at 8:08 PM, Tom Lane wrote:
>> I'm going to look at the YAML format for EXPLAIN patch shortly.
>
> Do we have consensus yet that we want YAML? It seemed, well,
> yet another format without all that much advantage over what's
> there.
Legibility++
David
--
Sent via pgsql-hack
Andrew Dunstan writes:
> As I have observed before, I think we need some infrastructure to help
> committers claim items, so we don't duplicate work.
Robert acknowledged the need for a "claimed by committer" field in the
fest application, but he hasn't got round to it yet. In the meantime
I've
Greg Smith wrote:
If the need here is to speed up how fast things are fed to committers,
we can certainly do that. The current process still favors having
reviewers do as much as possible first, as shown by all the stuff
sitting in the re-review queue. The work we're waiting on them for
Bruce Momjian wrote:
So, if someone writes a patch, and it is reviewed, and the patch author
updates the patch and replies, it still should be reviewed again before
being committed?
That's generally how things were expected to happen--to at least
double-check that the proposed fixes match what w
On Mon, Aug 3, 2009 at 11:22 AM, Tatsuo Ishii wrote:
>> > > Personally I was thinking of multi-threaded pgbench as being
>> > > Tatsuo-san's to commit, since that's his code originally.
>> >
>> > Ah see well that's why I post these summaries... :-)
>>
>> Thanks. I consider it a great honor to be al
> > > Personally I was thinking of multi-threaded pgbench as being
> > > Tatsuo-san's to commit, since that's his code originally.
> >
> > Ah see well that's why I post these summaries... :-)
>
> Thanks. I consider it a great honor to be allowed to commit the
> pacthes.
Patch committed.
--
Tatsu
> > Personally I was thinking of multi-threaded pgbench as being
> > Tatsuo-san's to commit, since that's his code originally.
>
> Ah see well that's why I post these summaries... :-)
Thanks. I consider it a great honor to be allowed to commit the
pacthes.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
On Sun, Aug 2, 2009 at 9:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> Unspecified Committer (3)
>> =
>> GRANT ON ALL IN schema
>> DefaultACLs
>> multi-threaded pgbench
>
> Personally I was thinking of multi-threaded pgbench as being
> Tatsuo-san's to commit, since that's his
Robert Haas writes:
> Unspecified Committer (3)
> =
> GRANT ON ALL IN schema
> DefaultACLs
> multi-threaded pgbench
Personally I was thinking of multi-threaded pgbench as being
Tatsuo-san's to commit, since that's his code originally.
regards, tom lane
We now have less than two weeks remaining in this CommitFest (assuming
we stick with the usual time table of one month), and I would say
we're in fairly good shape. There are less than a dozen patches left
that are waiting on people other than the committers, or that are
still under discussion. H
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
> Robert Haas writes:
>> ... One thing I have belatedly realized about this
>> CommitFest is that we (or at least, I) did not think about asking the
>> committers about their schedules, and it turns out that three of them
>> - Heikki
--On Sonntag, Juli 26, 2009 15:43:28 -0400 Robert Haas
wrote:
I think Joe is back in the next week, but I'm not sure about Michael or
Heikki.
Michael is on vacation, he's back next week.
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
Robert Haas wrote:
> I think Joe is back in the next week, but I'm not sure about Michael or
> Heikki.
I'll be back on Monday 3rd of August.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
On Sun, Jul 26, 2009 at 12:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... One thing I have belatedly realized about this
>> CommitFest is that we (or at least, I) did not think about asking the
>> committers about their schedules, and it turns out that three of them
>> - Heikki, Michael Meske
Robert Haas writes:
> ... One thing I have belatedly realized about this
> CommitFest is that we (or at least, I) did not think about asking the
> committers about their schedules, and it turns out that three of them
> - Heikki, Michael Meskes, Joe Conway - are away at the moment. About
> 25% of
All,
A few hours ago I assigned a reviewer to the last patch for this
CommitFest which still lacked one, with the exception of Heikki's
index-only quals patch, which I'm not sure can be reviewed at this
point because it depends on the indexam API changes patch, which is
still up in the air. One t
On Tuesday 01 July 2008 17:38:28 Josh Berkus wrote:
> On Tue, 01 Jul 2008 16:19:39 -0400
>
> Tom Lane <[EMAIL PROTECTED]> wrote:
> > Well, it's July 1, and time for another commit fest to begin.
> > Do we have all the submitted patches queued up at
> > http://wiki.postgresql.org/wiki/CommitFest:20
On Tue, Jul 1, 2008 at 4:19 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Well, it's July 1, and time for another commit fest to begin.
> Do we have all the submitted patches queued up at
> http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?
we noticed the libpq events (hooks) patch was missing...so
Zdenek Kotala napsal(a):
Tom Lane napsal(a):
Well, it's July 1, and time for another commit fest to begin.
Do we have all the submitted patches queued up at
http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?
There is Collation at database level patch.
http://archives.postgresql.org/pgsql-hac
Tom Lane napsal(a):
Well, it's July 1, and time for another commit fest to begin.
Do we have all the submitted patches queued up at
http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?
There is Collation at database level patch.
http://archives.postgresql.org/pgsql-hackers/2008-07/msg00019.php
On Tue, 01 Jul 2008 16:19:39 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Well, it's July 1, and time for another commit fest to begin.
> Do we have all the submitted patches queued up at
> http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?
I think Bruce and I have added everything submitted to
Joe Conway wrote:
> I haven't yet committed the dblink patch posted here:
>
> http://archives.postgresql.org/pgsql-patches/2008-06/msg00016.php
>
> Should I post it on the wiki before committing? Either way I'll commit
> in the next day or so.
It doesn't matter. Patches are only listed in the
1 - 100 of 127 matches
Mail list logo
