Re: Streaming replication and postmaster signaling

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Streaming replication and postmaster signaling
Дата
Msg-id 603c8f071001071145x16ab500et1ee5d3ea9c7e20ce@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Streaming replication and postmaster signaling  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Streaming replication and postmaster signaling
Re: Streaming replication and postmaster signaling
Список pgsql-hackers
On Thu, Jan 7, 2010 at 2:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> That may well be so, but adding another one is not going to improve
>> the situation even a little bit.  I don't think what you're saying
>> weakens in the slightest the argument that I was making, namely, that
>> if this isn't committed RSN it should be postponed to 8.6.  Do you
>> disagree?
>
> Well, the argument to my mind is about a suitable value of "RSN".
> I think you were stating that we should bounce SR if it's not committed
> before the final commitfest starts (ie, next week).  I think we can give
> it more slack than that.  Maybe the end of the fest (where the length of
> the fest is determined by the other open patches)?

We did that for 8.4 and I don't think it worked very well.  I think we
should have a HARD cutoff of one month for this CommitFest, just as we
have had for the other ones this cycle.  Anything we can't get through
by February 15th and isn't a release-blocker should just be pushed out
to 8.6.  It is not as if we have a big backlog of patches carried over
from previous CommitFests; we have only two of any size, that I am
aware of: SR and listen/notify.  Anything else that is adversely
affected by this policy is something that was submitted for only the
last CommitFest, and as long as we give those patches a fair review
and good feedback before bouncing them, I don't think we should feel
bad about postponing the ones that are not ready.

If you accept that principle then the question is whether SR should
have a different cut-off than the other patches in the CommitFest.  I
was being a bit coy about my position on that topic in my original
message and I'm still of two minds about it, but your mind-reading is
basically correct.  On the one hand, imposing an earlier deadline
might be viewed as moving the goalposts and I'm generally a big
opponent of that.  On the other hand, assuming that the amount of
community time Heikki gets is independent of what he's working on,
shooting SR through the head sooner means more time to stabilize HS,
which means an earlier release, and since there seems to be a
substantial danger that the release will be late no matter what we do,
I am tempted to say we should clamp down and go into damage control
mode sooner rather than later.

I am really reluctant to go through another cycle of giving a big
feature as much time as humanly possible before bouncing it, and then
bouncing it anyway, and I fear that is what will happen.  I don't
believe this patch has had a major rewrite since it was submitted for
the September CommitFest, and if 4 months hasn't been enough time to
get it committed, then why do we think the magic number is 5 rather
than 6 or 8 or anything else?  If someone has a concrete answer to
that question, I am all ears, but I feel like we're operating mostly
on hope.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Treat
Дата:
Сообщение: 8.5alpha3 hot standby crash report (DatabasePath related?)
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Streaming replication and postmaster signaling