Re: Hot standby and synchronous replication status

2009/8/11 Robert Haas <robertmhaas(at)gmail(dot)com>

> We should probably have a separate discussion about what the least
> committable unit would be for this patch. I wonder if it might be
> sufficient to provide a facility for streaming WAL, plus a standalone
> tool for receving it and storing it to a file. This might be designed
> as an improvement on our existing concept of an archive; the advantage
> would be that you could have all but perhaps the last few seconds of
> WAL if the primary kicked the bucket, rather than being behind by up
> to checkpoint_timeout. Allowing the WAL to be received directly by
> PostgreSQL could be a future enhancement.

That's an interesting idea. That would essentially be another method to set
up a WAL archive. I'm not sure it's worthwhile on its own, but once we have
the wal-sender infrastructure in place it should be easy to write such a
tool.

I think Hot Standby is in somewhat better shape. Having read the
> patch, I can say that it needs a pretty substantial amount of cleanup
> work: the code is messy. But Heikki was talking fairly seriously
> about committing this for 8.4, and everyone seems to agree that the
> architecture is approximately right. It's not clear to me how much
> more refactoring is needed or whether there are remaining bugs, but at
> least it looks to me like a reviewable version of the patch could be
> produced with a fairly modest amount of work.

That's my sentiment too. There's a fair amount of cleanup needed, the big
changes this spring left behind some damage to readability. I haven't looked
at your latest patch in detail, but it seems to go into the right direction,
thanks for that.

> Heikki stated (in response to a question from me) that he was not
> aware of anything that could be severed from Hot Standby and committed
> independently, and nothing jumped out at me when I read the patch
> either. But if the whole patch can be made committable in time then
> it's less critical.

Yeah, we still have time, but I am worried that if we let this patch sit for
another few months, we will be in the same situation when the 8.5 feature
freeze arrives that we were in 8.4. When it became clear that the patch
won't make it into 8.4, I thought we would continue working on the patch
throughout the spring and summer, and have a cleaned up patch ready for
review for the first 8.5 commit fest. I would be much more confident
committing a big patch like this early in the release cycle, with still
plenty of time left to uncover issues. That didn't happen. If we don't have
an updated patch for the 2nd commit fest, we're in serious risk of missing
the 8.5 release again.

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