Re: Hot Standby query cancellation and Streaming Replication integration

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Hot Standby query cancellation and Streaming Replication integration
Дата
Msg-id 407d949e1002261210v3793df96qb29bc5b9bf403535@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  (Aidan Van Dyk <aidan@highrise.ca>)
Re: Hot Standby query cancellation and Streaming Replication integration  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Feb 26, 2010 at 7:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

And when we want to support cascading slaves?

Or when you want to bring up a new slave and it suddenly starts
advertising a new xmin that's older than the current oldestxmin?

But in any case if I were running a reporting database I would want it
to just stop replaying logs for a few hours while my big batch report
runs, not cause the master to be unable to vacuum any dead records for
hours. That defeats much of the purpose of running the queries on the
slave.

--
greg


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Re: Hot Standby query cancellation and Streaming Replication integration
Следующее
От: Yeb Havinga
Дата:
Сообщение: Re: Avoiding bad prepared-statement plans.