Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
* need to fix mistaken code in FinishPreparedTransaction
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
In response to
pgsql-bugs by date
|Next:||From: Simon Riggs||Date: 2009-06-25 19:14:25|
|Subject: Re: BUG #4879: bgwriter fails to fsync the file in recoverymode|
|Previous:||From: Tom Lane||Date: 2009-06-25 19:03:22|
|Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |