On Tue, Apr 6, 2010 at 7:06 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Simon Riggs wrote:
>> I am surprised at your arguments for simplicity. With Hot Standby you
>> have insisted that everything should be in place. With SR you seem to
>> have just stopped at a barely working, poorly documented implementation.
>
> That's opposite to my recollection of the hot standby development. I
> simplified and ripped out a lot of stuff from the original patch.
>
> If you insist, I'll work out a patch to send a signal to startup process
> after every fsync(), but it really doesn't seem very important given
> that there's always a delay there anyway.
I would like to vote strongly against doing this. We all know that
Streaming Replication in 9.0 is not going to be as mature as we'd like
it to be; but we should be putting our time into fixing things that
are broken rather than tinkering with the avoidance of 100 ms waits.
>> We both know you can fix these things easily and quickly. Please do so.
>
> That's a plural form. What's the other thing you're referring to?
>
>> Not because I say so, but because everybody else will soon notice that
>> you could have and did not.
>
> Bollocks.
I've been thinking that the reason we weren't going to beta was
because of the SR open items, but I'm starting to think there's not
much left that really needs to be dealt with. The ones from that list
I think we should fix yet are:
- Walreceiver and dblink are not interruptible on win32.
- The documentation needs to be improved (if there's still more to do)
- Redefine smart shutdown in standby mode? (i'm working on this)
- The replication connections consume superuser_reserved_connections slots.
The other stuff strikes me as all window dressing. I also think we
need to deal with the shutdown checkpoint issue, which is HS rather
than SR.
...Robert
