On Thu, Jun 13, 2024 at 09:07:42PM +0300, m.litsarev@postgrespro.ru wrote:
> Hi!
>
> Michael,
> I have fixed the patches according to your comments.
>
> > merge both local variables into a single bits32 store?
> This is done in v3-0001-Standby-mode-requested.patch
>
> > Then this could be used with a function that returns a
> > text[] array with all the states retrieved?
> Placed this in the v3-0002-Text-array-sql-wrapper.patch
>
> > The refactoring pieces and the function pieces should be split, for
> > clarity.
> Sure. I also added the third patch with some tests. Perhaps it would be
> usefull.
+ * -- XLR_PROMOTE_IS_TRIGGERED indicates if a standby promotion
+ * has been triggered. Protected by info_lck.
+ *
+ * -- XLR_STANDBY_MODE_REQUESTED indicates if we're in a standby mode
+ * at start, while recovery mode is on. No info_lck protection.
+ *
+ * and can be extended in future.
This comment is incorrect for XLR_STANDBY_MODE_REQUESTED? A startup
we would unlikely be in standby mode, most likely in crash recovery,
then switch to standby mode.
- LocalPromoteIsTriggered = XLogRecoveryCtl->SharedPromoteIsTriggered;
+ LocalRecoveryDataFlags &= ~XLR_PROMOTE_IS_TRIGGERED;
+ LocalRecoveryDataFlags |=
+ (XLogRecoveryCtl->SharedRecoveryDataFlags & XLR_PROMOTE_IS_TRIGGERED)
Are these complications really needed? All these flags are false,
then switched to true. true -> false is not possible.
StandbyModeRequested = true;
ArchiveRecoveryRequested = true;
+ XLogRecoveryCtl->SharedRecoveryDataFlags |= XLR_STANDBY_MODE_REQUESTED;
Shouldn't STANDBY_MODE be only used in the local flag, as well as an
ARCHIVE_RECOVERY_REQUESTED? It looks like this could push a bit more
forward the removal of more of these booleans, with a bit more work..
return (LocalRecoveryDataFlags & XLR_HOT_STANDBY_ACTIVE);
}
+
/*
Some noise lying around.
+ /* Returns bit array as Datum */
+ txt_arr = construct_array_builtin(flags, cnt, TEXTOID);
Yep, that's the correct way to do it.
+is($ret_mode_primary, '{}', "master is not a replica");
The test additions are welcome. Note that we avoid the word "master",
see 229f8c219f8f.
--
Michael
