Re: Recovery Test Framework - Mailing list pgsql-hackers

Robert Haas wrote:
>> That's happened more than once, though my memory of details is fuzzy
>> and I don't have time to troll the archives for them right now.
>> Maybe Bruce can remember without a lot of searching.  But our current
>> policy of time-based releases (ie deadlines) is born of hard experience
>> with the negative consequences of saying "we'll release when feature X
>> is ready".  The real killer disadvantage is that all other development
>> tends to stop until X is ready, because no one can plan anything.
> 
> This is a very reasonable concern, and a good policy.  But I would
> feel better about the application of it to this particular case if
> you, personally, spent a couple of hours reviewing the patches at
> issue and expressed an opinion about how close they are to being ready
> to commit.  I doubt that many of us would care to substitute our
> judgment for yours - but it would be a shame to bump them to 8.5
> needlessly.

Well, I've been keeping an eye on both Hot Standby and Synchronous 
Replication patches. IMHO the Hot Standby patch is architecturally 
sound, and while I suggested some pretty big changes just recently 
(which Simon picked up and did already), it's in pretty good shape. No 
doubt there's still some issues that haven't been uncovered, comments to 
be fixed, documentation to be written, but no showstoppers or anything 
that requires a major rewrite. There's one todo item left: prepared 
transactions, but I don't think there's anything fundamentally hard 
about them, just needs to be fixed. Simon mentioned usability issues 
related to who/when queries get cancelled, but I think we've discussed 
that to death already and the patch handles it quite nicely.

IMHO, the synchronous replication isn't in such good shape, I'm afraid. 
I've said this before, but I'm not happy with the "built from spare 
parts" nature of it. You shouldn't have to configure an archive, 
file-based log shipping using rsync or whatever, and pg_standby. All 
that is in addition to the direct connection between master and slave. 
The slave really should be able to just connect to the master, and 
download all the WAL it needs directly. That's a huge usability issue if 
left as is, but requires very large architectural changes to fix.

> One thing I find interesting is that the "Infrastructure Changes for
> Recovery" patch became the foundation for both "Hot Standby" and
> "Synchronous Replication".  That implies that those changes might be
> of somewhat more general interest, at least as the foundation for
> further work.  If we HS and/or SR are out of reach, it might be worth
> at least looking to see if any of that infrastructure work can be
> reasonably be committed for 8.4.

Yeah, being able to do an online checkpoint after recovery has some 
value of its own.

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