Re: BUG #4879: bgwriter fails to fsync the file in recovery mode - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Date
Msg-id 24705.1245950722@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
List pgsql-bugs
Heikki Linnakangas <heikki.linnakangas@enterprisedb.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

pgsql-bugs by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Next
From: Tom Lane
Date:
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode