| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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 15:59:32 | 
| Message-ID: | 1245945572.4038.143.camel@ebony.2ndQuadrant | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
On Thu, 2009-06-25 at 11:31 -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> > Heikki Linnakangas wrote:
> >> Hmm, what happens when the startup process performs a write, and
> >> bgwriter is not running? Do the fsync requests queue up in the shmem
> >> queue until the end of recovery when bgwriter is launched? I guess I'll
> >> have to try it out...
> 
> > Oh dear, doesn't look good. The startup process has a pendingOpsTable of
> > its own. bgwriter won't fsync() files that the startup process has
> > written itself. That needs to be fixed, or you can lose data when an
> > archive recovery crashes after a restartpoint.
> 
> Ouch.  I'm beginning to think that the best thing is to temporarily
> revert the change that made bgwriter active during recovery. 
That seems the safest course, to avoid derailing the schedule.
Please define "temporarily". Will it be re-enabled in 8.4.1, assuming we
find an acceptable fix?
> It's
> obviously not been adequately thought through or tested.
Hmmm...
-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-06-25 16:03:30 | Re: BUG #4876: author of MD5 says it's seriously broken - hash collision resistance problems | 
| Previous Message | Heikki Linnakangas | 2009-06-25 15:57:47 | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |