Heikki Linnakangas <heikki.linnakan...@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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
