Re: Core team statement on replication in PostgreSQL
От | Marko Kreen |
---|---|
Тема | Re: Core team statement on replication in PostgreSQL |
Дата | |
Msg-id | e51f66da0805290840j71bfaaam70ff3a4054f22440@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Core team statement on replication in PostgreSQL (David Fetter <david@fetter.org>) |
Ответы |
Re: Core team statement on replication in PostgreSQL
|
Список | pgsql-hackers |
On 5/29/08, David Fetter <david@fetter.org> wrote: > On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote: > > Ideally this would be coupled with the ability to execute read-only > > queries on the slave servers, but we see technical difficulties that > > might prevent that from being completed before 8.5 or even further > > out. (The big problem is that long-running slave-side queries might > > still need tuples that are vacuumable on the master, and so > > replication of vacuuming actions would cause the slave's queries to > > deliver wrong answers.) > > This part is a deal-killer. It's a giant up-hill slog to sell warm > standby to those in charge of making resources available because the > warm standby machine consumes SA time, bandwidth, power, rack space, > etc., but provides no tangible benefit, and this feature would have > exactly the same problem. > > IMHO, without the ability to do read-only queries on slaves, it's not > worth doing this feature at all. I would not be so harsh - I'd like to have the lossless standby even without read-only slaves. But Tom's mail gave me impression core wants to wait until we get "perfect" read-only slave implementation so we wait with it until 8.6, which does not seem sensible. If we can do slightly inefficient (but simple) implementation right now, I see no reason to reject it, we can always improve it later. Especially as it can be switchable. And we could also have transaction_timeout paramenter on slaves so the hit on master is limited. -- marko
В списке pgsql-hackers по дате отправления: