Skip site navigation (1) Skip section navigation (2)

Re: Keepalive for max_standby_delay

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Keepalive for max_standby_delay
Date: 2010-05-31 18:40:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Uh, we have three days before we package 9.0beta2.  It would be good if
we could decide on the max_standby_delay issue soon.


Simon Riggs wrote:
> 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 

[ Attachment, skipping... ]

> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + None of us is going to be here forever. +

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-05-31 18:54:57
Subject: Re: fillfactor gets set to zero for toast tables
Previous:From: Tom LaneDate: 2010-05-31 18:38:19
Subject: Re: tsvector pg_stats seems quite a bit off.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group