Re: Re: Hot Standby query cancellation and Streaming Replication integration
От | Robert Haas |
---|---|
Тема | Re: Re: Hot Standby query cancellation and Streaming Replication integration |
Дата | |
Msg-id | 603c8f071002271700t1bffd309r8b8838189d4c827e@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: Hot Standby query cancellation and Streaming Replication integration (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: Hot Standby query cancellation and Streaming Replication
integration
|
Список | pgsql-hackers |
On Fri, Feb 26, 2010 at 1:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Greg Stark <gsstark@mit.edu> writes: >> In the model you describe any long-lived queries on the slave cause >> tables in the master to bloat with dead records. > > Yup, same as they would do on the master. > >> I think this model is on the roadmap but it's not appropriate for >> everyone and I think one of the benefits of having delayed it is that >> it forces us to get the independent model right before throwing in >> extra complications. It would be too easy to rely on the slave >> feedback as an answer for hard questions about usability if we had it >> and just ignore the question of what to do when it's not the right >> solution for the user. > > I'm going to make an unvarnished assertion here. I believe that the > notion of synchronizing the WAL stream against slave queries is > fundamentally wrong and we will never be able to make it work. > The information needed isn't available in the log stream and can't be > made available without very large additions (and consequent performance > penalties). As we start getting actual beta testing we are going to > uncover all sorts of missed cases that are not going to be fixable > without piling additional ugly kluges on top of the ones Simon has > already crammed into the system. Performance and reliability will both > suffer. > > I think that what we are going to have to do before we can ship 9.0 > is rip all of that stuff out and replace it with the sort of closed-loop > synchronization Greg Smith is pushing. It will probably be several > months before everyone is forced to accept that, which is why 9.0 is > not going to ship this year. Somewhat unusually for me, I haven't been able to keep up with my email over the last few days, so I'm weighing in on this one a bit late. It seems to me that if we're forced to pass the xmin from the slave back to the master, that would be a huge step backward in terms of both scalability and performance, so I really hope it doesn't come to that. I wish I understood better exactly what you mean by "the notion of synchronizing the WAL stream against slave queries" and why you don't think it will work. Can you elaborate? ...Robert
В списке pgsql-hackers по дате отправления: