Re: damage control mode

On Thu, Jan 7, 2010 at 10:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> OK, we have a proposal on the table to bump some patches from this
>> CommitFest to free up more committer resources, particularly Tom, to
>> work on Hot Standby and Streaming Replication and attempt to
>> accelerate the process of getting 8.5 out the door.  This proposal
>> needs input from the community.  The affected patches are:
>
>> - Listen/Notify Rewrite.
>> - Writeable CTEs.
>> - more frame options for window functions
>> - knngist
>> - rbtree
>
> Looking at this list again, it strikes me that the listen/notify rewrite
> might need to go in so that we have a sane framework for listen/notify
> with HS.  Treating pg_listener as a replicatable table isn't sane at
> all, whereas with a message-driven notify mechanism we have at least got
> the possibility of shipping the messages to the standby (via WAL) and
> having listeners there.  I don't want to say we'd actually implement
> that in 8.5, but shipping pg_listener tuple updates is just completely
> nuts.

It's also related to this open issue, so possibly we could kill two
birds with one stone (although I guess that would still leave the
problem of what to do in the back branches).

http://archives.postgresql.org/pgsql-bugs/2009-12/msg00274.php

> The other four things have no apparent connection to HS/SR so I think
> they could be punted without creating technical issues.  Whether this
> is really necessary from a schedule viewpoint is not clear yet.
>
> My thought about it would be to put these four on the back burner;
> not necessarily bounce them right away, but not put any effort into
> them until we have dealt with the other stuff in the January CF.
> At that point we should have a feel for where we are schedule-wise,
> and in particular we'll know whether SR is in or not ;-)

That seems wishy-washy. If we're going to have any chance of getting
these patches in, we have to give the patch authors good feedback
early in the CommitFest so that they have time to make the necessary
revisions before the end of the CommitFest. If we think we can swing
it, I'm happy to handle these patches in the normal way; I'm also
happy to say we'll review them all but not commit them for fear of
destabilizing the tree; or we can punt them altogether. We can also
pick and choose. But saying we're going to postpone dealing with them
doesn't seem to me to solve anything.

I also think that postponement is not going to buy us very much time
anyway. Most of them are pretty small.

If SR is in, does that militate toward bumping the patches (because
now we have more potential bugs to fix) or against it (because now you
don't have to help make it committable)?

...Robert