Re: Sync Rep: First Thoughts on Code
От | Simon Riggs |
---|---|
Тема | Re: Sync Rep: First Thoughts on Code |
Дата | |
Msg-id | 1228921185.20796.850.camel@hp_dx2400_1 обсуждение исходный текст |
Ответ на | Re: Sync Rep: First Thoughts on Code (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Sync Rep: First Thoughts on Code
|
Список | pgsql-hackers |
On Wed, 2008-12-10 at 14:39 +0200, Heikki Linnakangas wrote: > In the current form, is there any reason why walreceiver needs to be > an integrated server process? Couldn't it just be a stand-alone > program that connects to the primary and writes the received records > to the right WAL file? The only reason I can see is to reliably kill > it when the standby server is promoted to primary. Reasons: * integration: we have one service we stop and start, not two. We want one log, one set of commands, one set of parameters etc * cooperation: if wal receiver is a server process we can reasonably communicate the current WAL limit via shared memory. That gives us smooth flow of WAL between receiver and replay (startup process) rather than a burst of activity each time a file arrives. That helps smooth performance and minimises failover time. Without this we would need to retain the concept of archive_timeout on the primary even when streaming, which is fairly strange. * code management Other than that there isn't that much in it... We've all read the stuff about how other RDBMS come with integrated replication. We *can* make this integrated, robust and very very easy to use, yet with flexibility for a variety of purposes. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: