On Tue, Sep 20, 2022 at 7:46 PM Amul Sul <sula...@gmail.com> wrote:
>
Thanks for the review
> Here are a few minor suggestions I came across while reading this
> patch, might be useful:
>
> +#ifdef USE_ASSERT_CHECKING
> +
> + {
>
> Unnecessary space after USE_ASSERT_CHECKING.
Changed
>
> + return InvalidRelFileNumber; /* placate compiler */
>
> I don't think we needed this after the error on the latest branches.
> --
Changed
> + LWLockAcquire(RelFileNumberGenLock, LW_SHARED);
> + if (shutdown)
> + checkPoint.nextRelFileNumber = ShmemVariableCache->nextRelFileNumber;
> + else
> + checkPoint.nextRelFileNumber =
> ShmemVariableCache->loggedRelFileNumber;
> +
> + LWLockRelease(RelFileNumberGenLock);
>
> This is done for the good reason, I think, it should have a comment
> describing different checkPoint.nextRelFileNumber assignment
> need and crash recovery perspective.
> --
Done
> +#define SizeOfRelFileLocatorBackend \
> + (offsetof(RelFileLocatorBackend, backend) + sizeof(BackendId))
>
> Can append empty parenthesis "()" to the macro name, to look like a
> function call at use or change the macro name to uppercase?
> --
Yeah we could SizeOfXXX macros are general practice I see used
everywhere in Postgres code so left as it is.
> + if (val < 0 || val > MAX_RELFILENUMBER)
> ..
> if ((relfilenumber) < 0 || (relfilenumber) > MAX_RELFILENUMBER) \
>
> How about adding a macro for this condition as RelFileNumberIsValid()?
> We can replace all the checks referring to MAX_RELFILENUMBER with this.
Actually, RelFileNumberIsValid is used to just check whether it is
InvalidRelFileNumber value i.e. 0. Maybe for this we can introduce
RelFileNumberInValidRange() but I am not sure whether it would be
cleaner than what we have now, so left as it is for now.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
