Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
От | Tom Lane |
---|---|
Тема | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |
Дата | |
Msg-id | 26475.1245957005@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: BUG #4879: bgwriter fails to fsync the file in recovery
mode
Re: BUG #4879: bgwriter fails to fsync the file in recovery mode Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |
Список | pgsql-bugs |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > Tom Lane wrote: >> On the other point: are we going to eliminate mdunlink's isRedo >> parameter? Maybe the better thing is to have its callers pass the value >> of InArchiveRecovery? > I think my initial analysis of this bug was bogus. There's nothing wrong > with mdunlink() as it is, it's calling ForgetRelationFsyncRequests() > before it unlinks anything, regardless of the isRedo parameter. In > Fujii-san's scenario, it was just going to the pendingOpsTable of the > startup process and not sent to bgwriter as it should. Setting > pendingOpsTable=NULL when bgwriter is launched will fix that. +1, I think that's okay. So to summarize the state of play, it seems we have these issues: * need to delete startup process's local pendingOpsTable once bgwriter is launched, so that requests go to bgwriter instead * need to push end-of-recovery checkpoint into bgwriter * need to do something about IsRecovery tests that will now be executed in bgwriter * need to fix mistaken code in FinishPreparedTransaction Anything else? Are you (Heikki and Simon) in a position to finish these things today? I know it's starting to get late on your side of the pond. Core have already been discussing whether we have to abort the release for this. regards, tom lane
В списке pgsql-bugs по дате отправления: