>> The question remains whether saving off a few fsyncs/reads for these
>> long-lived prepared transactions is worth the additional code churn.
>> Even if we add code to go through the KnownPreparedList, we still will
>> have to go through the other on-disk 2PC transactions anyways. So,
>> maybe not.
>
> We should really try to do things right now, or we'll never come back
> to it. 9.3 (if my memory does not fail me?) has reduced the time to do
> promotion by removing the need of the end-of-recovery checkpoint,
> while I agree that there should not be that many 2PC transactions at
> this point, if there are for a reason or another, the time it takes to
> complete promotion would be impacted. So let's refactor
> PrescanPreparedTransactions() so as it is able to handle 2PC data from
> a buffer extracted by XlogReadTwoPhaseData(), and we are good to go.
>
Not quite. If we modify PrescanPreparedTransactions(), we also need to
make RecoverPreparedTransactions() and
StandbyRecoverPreparedTransactions() handle 2PC data via
XlogReadTwoPhaseData().
> + /*
> + * Move prepared transactions, if any, from KnownPreparedList to files.
> + * It is possible to skip this step and teach subsequent code about
> + * KnownPreparedList, but PrescanPreparedTransactions() happens once
> + * during end of recovery or on promote, so probably it isn't worth
> + * the additional code.
> + */
This comment is misplaced. Does not make sense before this specific call.
> + KnownPreparedRecreateFiles(checkPoint.redo);
> RecoveryRestartPoint(&checkPoint);
> Looking again at this code, I think that this is incorrect. The
> checkpointer should be in charge of doing this work and not the
> startup process, so this should go into CheckpointTwoPhase() instead.
I don't see a function by the above name in the code?
Regards,
Nikhils
-- Nikhil Sontakke http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services