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

Re: BUG #4879: bgwriter fails to fsync the file in recovery mode

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Date: 2009-06-25 19:38:53
Message-ID: 27738.1245958733@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> ... I think it might be better to fix
>> things so that InRecovery is maintained correctly in the bgwriter too.

> We could set InRecovery=true in CreateCheckPoint if it's a startup
> checkpoint, and reset it afterwards. I'm not 100% sure it's safe to have
> bgwriter running with InRecovery=true at other times. Grepping for
> InRecovery doesn't show anything that bgwriter calls, but it feels safer
> that way.

Actually, my thought was exactly that it would be better if it was set
correctly earlier in the run --- if there ever are any places where it
matters, this way is more likely to be right.  (I'm not convinced that
it doesn't matter today, anyhow --- are we sure these places are not
called in a restartpoint?)

What you suggest might be a good minimum-change solution for right now,
but I think eventually it should work the other way.

> Hmm, I see another small issue. We now keep track of the "minimum
> recovery point". Whenever a data page is flushed, we set minimum
> recovery point to the LSN of the page in XLogFlush(), instead of
> fsyncing WAL like we do in normal operation. During the end-of-recovery
> checkpoint, however, RecoveryInProgress() returns false, so we don't
> update minimum recovery point in XLogFlush(). You're unlikely to be
> bitten by that in practice; you would need to crash during the
> end-of-recovery checkpoint, and then set the recovery target to an
> earlier point. It should be fixed nevertheless.

We would want the end-of-recovery checkpoint to act like it's not in
recovery anymore for this purpose, no?

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-06-25 19:50:24
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Previous:From: Dustin ParkerDate: 2009-06-25 19:38:21
Subject: BUG #4882: One-click installer crashes with certain service account passwords

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