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 | 1245992374.4038.353.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: BUG #4879: bgwriter fails to fsync the file in recovery
mode
|
Список | pgsql-bugs |
On Fri, 2009-06-26 at 05:14 +0100, Simon Riggs wrote: > On Thu, 2009-06-25 at 20:25 -0400, Tom Lane wrote: > > What I am thinking is that instead of the hack of clearing > > LocalRecoveryInProgress to allow the current process to write WAL, > > we should have a separate test function WALWriteAllowed() with a > > state variable LocalWALWriteAllowed, and the hack should set that > > state without playing any games with LocalRecoveryInProgress. Then > > RecoveryInProgress() remains true during the end-of-recovery checkpoint > > and we can condition the TruncateMultiXact and TruncateSUBTRANS calls > > on that. Meanwhile the various places that check RecoveryInProgress > > to decide if WAL writing is allowed should call WALWriteAllowed() > > instead. > > No need. Belay that. Yes, agree need for additional state, though think its more like EndRecoveryIsComplete(). -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
В списке pgsql-bugs по дате отправления: