Re: Core team statement on replication in PostgreSQL
От | Robert Treat |
---|---|
Тема | Re: Core team statement on replication in PostgreSQL |
Дата | |
Msg-id | 200805301516.30049.xzilla@users.sourceforge.net обсуждение исходный текст |
Ответ на | Re: Core team statement on replication in PostgreSQL (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Core team statement on replication in PostgreSQL
|
Список | pgsql-hackers |
On Friday 30 May 2008 01:10:20 Tom Lane wrote: > Greg Smith <gsmith@gregsmith.com> writes: > > I fully accept that it may be the case that it doesn't make technical > > sense to tackle them in any order besides sync->read-only slaves because > > of dependencies in the implementation between the two. > > Well, it's certainly not been my intention to suggest that no one should > start work on read-only-slaves before we finish the other part. The > point is that I expect the log shipping issues will be done first > because they're easier, and it would be pointless to not release that > feature if we had it. > > But since you mention it: one of the plausible answers for fixing the > vacuum problem for read-only slaves is to have the slaves push an xmin > back upstream to the master to prevent premature vacuuming. The current > design of pg_standby is utterly incapable of handling that requirement. > So there might be an implementation dependency there, depending on how > we want to solve that problem. > Sure, but whose to say that after synchronous wal shipping is "finished" it wont need a serious re-write due to new needs from the hot standby feature. I think going either way carries some risk. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
В списке pgsql-hackers по дате отправления: