Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
От | Simon Riggs |
---|---|
Тема | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |
Дата | |
Msg-id | 1245952509.4038.179.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #4879: bgwriter fails to fsync the file in recovery
mode
|
Список | pgsql-bugs |
On Thu, 2009-06-25 at 13:25 -0400, Tom Lane wrote: > 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. I think that's because FinishPreparedTransaction() implicitly assumes that if a file still exists we are in recovery. I can't comment on whether that is necessarily true for some reason, but it doesn't sound like it is a safe assumption. I would guess it's using isRedo as an implicit override rather than using the correct meaning of the variable. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
В списке pgsql-bugs по дате отправления: