Re: Pluggable Indexes (was Re: rmgr hooks (v2)) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Pluggable Indexes (was Re: rmgr hooks (v2))
Date
Msg-id 4978913A.1070401@enterprisedb.com
Whole thread Raw
In response to Re: Pluggable Indexes (was Re: rmgr hooks (v2))  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Pluggable Indexes (was Re: rmgr hooks (v2))  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas wrote:
> The fact the patch does not do anything that anyone might ever want is
> not a sufficient grounds for rejecting it.

Huh? That sounds like enough of a reason to me.

> Much ink has been spilled in this space over the size and difficulty
> of reviewing Simon's hot standby patch, on the grounds that it is big
> and changed many things.  Of course, Simon did submit an earlier
> version of this patch that was less big and changed fewer things, and
> it was never committed even though Simon responded to all of the
> review comments.

What patch was that?

>  In fact, even after you took the time to split it
> back out again, and even after acknowledging that the split-out part
> was good code and independently useful, you never committed THAT
> either.  And so here we sit in limbo.

I did split the "recovery infrastructure" patch from the hot standby 
patch. I still intend to review and hopefully commit that (I'll need to 
split the latest version from the hot standby patch again). When I 
reviewed it for the first time, I just didn't feel that I understood it 
well enough to commit it. But that's a completely different patch than 
what we're talking about now.

> If you now reject this patch because it is small and changes too few
> things, then will you reject his next patch that is more comprehensive
> on the grounds that the patch is now too big to review?

I won't and haven't rejected a patch because it's too big to review. I 
admit that a big patch is a lot harder and more time consuming to 
review, so I might not have the time or desire to review it. But that's 
a different story.

> I wonder what Simon has to do to get a patch committed.  It's been
> four months since he started submitting patches, and so far the only
> thing that's been committed is the pg_stop_backup() wait bug fix.  If
> the code were bad or required a lot of fixing to get it in committable
> form, that would be completely understandable but no one is alleging
> that.

You're confusing things. I'm objecting this rmgr patch, but I'm spending 
all the spare time I have to review the hot standby patch. It *does* and 
*has* required a lot of fixing to get it into committable form. I feel 
that it's pretty close now, but I'm waiting for his latest version and I 
still need to go through it more closely before I feel comfortable 
enough to commit.

(I should also say that if any of the other committers feels differently 
and wants to pick up this rmgr patch and commit it, that's fine with me 
(assuming the code is fine))

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: libpq WSACleanup is not needed
Next
From: Alvaro Herrera
Date:
Subject: Re: Pluggable Indexes