Re: Keepalive for max_standby_delay

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Keepalive for max_standby_delay
Дата
Msg-id 1274981186.4405.100.camel@ebony
обсуждение исходный текст
Ответ на Re: Keepalive for max_standby_delay  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Keepalive for max_standby_delay  (Bruce Momjian <bruce@momjian.us>)
Re: Keepalive for max_standby_delay  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Keepalive for max_standby_delay  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, 2010-05-26 at 16:22 -0700, Josh Berkus wrote:
> > Just this second posted about that, as it turns out.
> >
> > I have a v3 *almost* ready of the keepalive patch. It still makes sense
> > to me after a few days reflection, so is worth discussion and review. In
> > or out, I want this settled within a week. Definitely need some R&R
> > here.
>
> Does the keepalive fix all the issues with max_standby_delay?  Tom?

OK, here's v4.

Summary

* WALSender adds a timestamp onto the header of every WAL chunk sent.

* Each WAL record now has a conceptual "send timestamp" that remains
constant while that record is replayed. This is used as the basis from
which max_standby_delay is calculated when required during replay.

* Send timestamp is calculated as the later of the timestamp of chunk in
which WAL record was sent and the latest XLog time.

* WALSender sends an empty message as a keepalive when nothing else to
send. (No longer a special message type for the keepalive).

I think its close, but if there's a gaping hole here somewhere then I'll
punt for this release.

--
 Simon Riggs           www.2ndQuadrant.com

Вложения

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

Предыдущее
От: Ray Stell
Дата:
Сообщение: Re: [ADMIN] command tag logging
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: functional call named notation clashes with SQL feature