Re: Re: Hot Standby query cancellation and Streaming Replication integration
От | Tom Lane |
---|---|
Тема | Re: Re: Hot Standby query cancellation and Streaming Replication integration |
Дата | |
Msg-id | 2425.1267211800@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: Hot Standby query cancellation and Streaming Replication integration (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Re: Hot Standby query cancellation and Streaming Replication
integration
Re: Re: Hot Standby query cancellation and Streaming Replication integration Re: Hot Standby query cancellation and Streaming Replication integration Re: Re: Hot Standby query cancellation and Streaming Replication integration |
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: > On 2/26/10 10:53 AM, Tom Lane wrote: >> 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. > I don't think that publishing visibility info back to the master ... and > subsequently burdening the master substantially for each additional > slave ... are what most users want. I don't see a "substantial additional burden" there. What I would imagine is needed is that the slave transmits a single number back --- its current oldest xmin --- and the walsender process publishes that number as its transaction xmin in its PGPROC entry on the master. I don't doubt that this approach will have its own gotchas that we find as we get into it. But it looks soluble. I have no faith in either the correctness or the usability of the approach currently being pursued. regards, tom lane
В списке pgsql-hackers по дате отправления: