Re: Re: Hot Standby query cancellation and Streaming Replication integration
От | Josh Berkus |
---|---|
Тема | Re: Re: Hot Standby query cancellation and Streaming Replication integration |
Дата | |
Msg-id | 4B8828C0.7030501@agliodbs.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
Re: Re: Hot Standby query cancellation and StreamingReplication integration |
Список | pgsql-hackers |
> 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. If the main purpose of the slave is long-running queries, though, this could cause a lot of bloat on the master. That's a special case, but a reason why we would want to preserve the stop replication functionality. > 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. So, why not start working on it now, instead of arguing about it? It'll be easy to prove the approach once we have some test code.
В списке pgsql-hackers по дате отправления: