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

Re: [HACKERS] Re: pgsql: Use a latch to make startup process wake up and replay

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Heikki Linnakangas <heikki(at)postgresql(dot)org>, pgsql-committers(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: pgsql: Use a latch to make startup process wake up and replay
Date: 2010-09-15 18:19:44
Message-ID: 4C910E40.9000206@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On 15/09/10 20:58, Robert Haas wrote:
> On Wed, Sep 15, 2010 at 1:30 PM, Simon Riggs<simon(at)2ndquadrant(dot)com>  wrote:
>> On Wed, 2010-09-15 at 12:45 -0400, Robert Haas wrote:
>>> On Wed, Sep 15, 2010 at 11:24 AM, Simon Riggs<simon(at)2ndquadrant(dot)com>  wrote:
>>>> I agree that asking people to stop work is not OK. However, I haven't
>>>> asked for development work to stop, only that commits into that area
>>>> stop until proper debate has taken place. Those might be minor commits,
>>>> but they might not. Had I made those commits, they would have been
>>>> called premature by others also.
>>>
>>> I do not believe that Heikki has done anything inappropriate.  We've
>>> spent weeks discussing the latch facility and its various
>>> applications.
>>
>> Sounds reasonable, but my comments were about this commit, not the one
>> that happened on Saturday. This patch was posted about 32 hours ago, and
>> the commit need not have taken place yet. If I had posted such a patch
>> and committed it knowing other work is happening in that area we both
>> know that you would have objected.
>
> I've often felt that we ought to have a bit more delay between when
> committers post patches and when they commit them.  I was told 24
> hours and I've seen cases where people haven't even waited that long.
> On the other hand, if we get to strict about it, it can easily get to
> the point where it just gets in the way of progress, and certainly
> some patches are far more controversial than others.  So I don't know
> what the best thing to do is.

With anything non-trivial, I try to "sleep on it" before committing. 
More with complicated patches, but it's really up to your own comfort 
level with the patch, and whether you think anyone might have different 
opinions on it. I don't mind quick commits if it's something that has 
been discussed in the past and the committer thinks it's 
non-controversial. There's always the option of complaining afterwards. 
If it comes to that, though, it wasn't really ripe for committing yet. 
(That doesn't apply to gripes about typos or something like that, 
because that happens to me way too often ;-) )

>  Still, I have to admit that I feel
> fairly positive about the direction we're going with this particular
> patch.  Clearing away these peripheral issues should make it easier
> for us to have a rational discussion about the core issues around how
> this is going to be configured and actually work at the protocol
> level.

Yeah, I don't think anyone has any qualms about the substance of these 
patches.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-09-15 18:21:40
Subject: Re: patch: SQL/MED(FDW) DDL
Previous:From: Robert HaasDate: 2010-09-15 17:58:26
Subject: Re: [HACKERS] Re: pgsql: Use a latch to make startup process wake up and replay

pgsql-committers by date

Next:From: Simon RiggsDate: 2010-09-15 19:18:02
Subject: Re: [HACKERS] Re: pgsql: Use a latch to make startup process wake up and replay
Previous:From: Robert HaasDate: 2010-09-15 17:58:26
Subject: Re: [HACKERS] Re: pgsql: Use a latch to make startup process wake up and replay

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