Re: max_standby_delay considered harmful

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: max_standby_delay considered harmful
Date: 2010-05-05 20:49:25
Message-ID: 1273092565.4535.4767.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2010-05-05 at 16:46 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > The attached patch redefines "standby delay" to be the amount of time
> > elapsed from point of receipt to point of application. The "point of
> > receipt" is reset every chunk of data when streaming, or every file when
> > reading file by file. In all cases this new time is later than the
> > latest log time we would have used previously.
>
> This seems completely wrong to me. If the WAL receiver keeps receiving
> stuff, (last receive timestamp) - (current timestamp) would never be
> more than a few seconds. Regardless of how much applying the WAL has
> fallen behind.

I see your point.

> To accomplish what you're trying to accomplish, you would need to label
> each received WAL record with the timestamp when it was received, and
> compare the reception timestamp of the record you're applying against
> current timestamp.

Yes, OK. Obviously doing it for every record would be silly, so sampling
WAL records is the only way. If we save the timestamp every 16MB of WAL
that would work for both file and streaming.

Of course, if WAL was written regularly none of this would be a problem.
Why not have WALSender write a new WAL record with a timestamp every X
seconds?

--
Simon Riggs www.2ndQuadrant.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-05-05 20:51:12 Re: max_standby_delay considered harmful
Previous Message Jesper Krogh 2010-05-05 18:55:10 Re: pg_migrator to /contrib in a later 9.0 beta