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 17:25:22
Message-ID: 24705.1245950722@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> It's tempting to just remove the "!isRedo" condition, but then we have
> another problem: if bgwriter hasn't been started yet, and the shmem
> queue is full, we get stuck in register_unlink() trying to send the
> message and failing.

> In archive recovery, we always start bgwriter at the beginning of WAL
> replay. In crash recovery, we don't start bgwriter until the end of wAL
> replay. So we could change the "!isRedo" condition to
> "!InArchiveRecovery". It's not a very clean solution, but it's simple.

I looked through the callers of smgrdounlink(), and found that
FinishPreparedTransaction passes isRedo = true.  I'm not sure at the
moment what the reasoning behind that was, but it does seem to mean that
checking InArchiveRecovery instead of isRedo may not be quite right.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-06-25 17:34:11
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Previous:From: Heikki LinnakangasDate: 2009-06-25 17:12:19
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode

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