Re: Hot standby and synchronous replication status - Mailing list pgsql-hackers
| From | Heikki Linnakangas |
|---|---|
| Subject | Re: Hot standby and synchronous replication status |
| Date | |
| Msg-id | 7bbd365e0908102250t7b2cc656hd1b6654c86b65d3@mail.gmail.com Whole thread Raw |
| In response to | Re: Hot standby and synchronous replication status (Robert Haas <robertmhaas@gmail.com>) |
| Responses |
Re: Hot standby and synchronous replication status
(Magnus Hagander <magnus@hagander.net>)
Re: Hot standby and synchronous replication status (Dimitri Fontaine <dfontaine@hi-media.com>) |
| List | pgsql-hackers |
2009/8/11 Robert Haas <robertmhaas@gmail.com>
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.
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.
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.
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
pgsql-hackers by date: