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 18:46:08
Message-ID: 26048.1245955568@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Here's a patch taking that approach, and I think it's better than the
> previous one. I was afraid we would lose robustness if we have to set
> the shared state as "out of recovery" before requesting the checkpoint,
> but we can use the same trick we were using in startup process and set
> LocalRecoveryInProgress=false before setting the shared variable. I
> introduced a new CHECKPOINT_IS_STARTUP flag,

This isn't a "startup" checkpoint, it's an "end of recovery" checkpoint,
because we don't do it during normal startup. Not sure about an equally
concise name based on that, but I don't like IS_STARTUP.

On the other point: are we going to eliminate mdunlink's isRedo
parameter? Maybe the better thing is to have its callers pass the value
of InArchiveRecovery?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2009-06-25 18:59:56 Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Previous Message Heikki Linnakangas 2009-06-25 18:40:33 Re: BUG #4879: bgwriter fails to fsync the file in recovery mode