8000 Reorder two functions in inval.c · postgres/postgres@c2bdd2c · GitHub
[go: up one dir, main page]
Skip to content

Commit c2bdd2c

Browse files
michaelpqmichaelpq
committed
Reorder two functions in inval.c
This file separates public and static functions with a separator comment, but two routines were not defined in a location reflecting that, so reorder them. Author: Aleksander Alekseev Reviewed-by: Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/CAJ7c6TMX2dd0g91UKvcC+CVygKQYJkKJq1+ZzT4rOK42+b53=w@mail.gmail.com
1 parent ac7d6f5 commit c2bdd2c

File tree

1 file changed

+91
-92
lines changed

1 file changed

+91
-92
lines changed

‎src/backend/utils/cache/inval.c

Lines changed: 91 additions & 92 deletions
Original file line numberDiff line numberDiff line change
@@ -604,6 +604,97 @@ RegisterSnapshotInvalidation(Oid dbId, Oid relId)
604604
dbId, relId);
605605
}
606606

607+
/*
608+
* PrepareInvalidationState
609+
* Initialize inval data for the current (sub)transaction.
610+
*/
611+
static void
612+
PrepareInvalidationState(void)
613+
{
614+
TransInvalidationInfo *myInfo;
615+
616+
if (transInvalInfo != NULL &&
617+
transInvalInfo->my_level == GetCurrentTransactionNestLevel())
618+
return;
619+
620+
myInfo = (TransInvalidationInfo *)
621+
MemoryContextAllocZero(TopTransactionContext,
622+
sizeof(TransInvalidationInfo));
623+
myInfo->parent = transInvalInfo;
624+
myInfo->my_level = GetCurrentTransactionNestLevel();
625+
626+
/* Now, do we have a previous stack entry? */
627+
if (transInvalInfo != NULL)
628+
{
629+
/* Yes; this one should be for a deeper nesting level. */
630+
Assert(myInfo->my_level > transInvalInfo->my_level);
631+
632+
/*
633+
* The parent (sub)transaction must not have any current (i.e.,
634+
* not-yet-locally-processed) messages. If it did, we'd have a
635+
* semantic problem: the new subtransaction presumably ought not be
636+
* able to see those events yet, but since the CommandCounter is
637+
* linear, that can't work once the subtransaction advances the
638+
* counter. This is a convenient place to check for that, as well as
639+
* being important to keep management of the message arrays simple.
640+
*/
641+
if (NumMessagesInGroup(&transInvalInfo->CurrentCmdInvalidMsgs) != 0)
642+
elog(ERROR, "cannot start a subtransaction when there are unprocessed inval messages");
643+
644+
/*
645+
* MemoryContextAllocZero set firstmsg = nextmsg = 0 in each group,
646+
* which is fine for the first (sub)transaction, but otherwise we need
647+
* to update them to follow whatever is already in the arrays.
648+
*/
649+
SetGroupToFollow(&myInfo->PriorCmdInvalidMsgs,
650+
&transInvalInfo->CurrentCmdInvalidMsgs);
651+
SetGroupToFollow(&myInfo->CurrentCmdInvalidMsgs,
652+
&myInfo->PriorCmdInvalidMsgs);
653+
}
654+
else
655+
{
656+
/*
657+
* Here, we need only clear any array pointers left over from a prior
658+
* transaction.
659+
*/
660+
InvalMessageArrays[CatCacheMsgs].msgs = NULL;
661+
InvalMessageArrays[CatCacheMsgs].maxmsgs = 0;
662+
InvalMessageArrays[RelCacheMsgs].msgs = NULL;
663+
InvalMessageArrays[RelCacheMsgs].maxmsgs = 0;
664+
}
665+
666+
transInvalInfo = myInfo;
667+
}
668+
669+
/* ----------------------------------------------------------------
670+
* public functions
671+
* ----------------------------------------------------------------
672+
*/
673+
674+
void
675+
InvalidateSystemCachesExtended(bool debug_discard)
676+
{
677+
int i;
678+
679+
InvalidateCatalogSnapshot();
680+
ResetCatalogCaches();
681+
RelationCacheInvalidate(debug_discard); /* gets smgr and relmap too */
682+
683+
for (i = 0; i < syscache_callback_count; i++)
684+
{
685+
struct SYSCACHECALLBACK *ccitem = syscache_callback_list + i;
686+
687+
ccitem->function(ccitem->arg, ccitem->id, 0);
688+
}
689+
690+
for (i = 0; i < relcache_callback_count; i++)
691+
{
692+
struct RELCACHECALLBACK *ccitem = relcache_callback_list + i;
693+
694+
ccitem->function(ccitem->arg, InvalidOid);
695+
}
696+
}
697+
607698
/*
608699
* LocalExecuteInvalidationMessage
609700
*
@@ -704,36 +795,6 @@ InvalidateSystemCaches(void)
704795
InvalidateSystemCachesExtended(false);
705796
}
706797

707-
void
708-
InvalidateSystemCachesExtended(bool debug_discard)
709-
{
710-
int i;
711-
712-
InvalidateCatalogSnapshot();
713-
ResetCatalogCaches();
714-
RelationCacheInvalidate(debug_discard); /* gets smgr and relmap too */
715-
716-
for (i = 0; i < syscache_callback_count; i++)
717-
{
718-
struct SYSCACHECALLBACK *ccitem = syscache_callback_list + i;
719-
720-
ccitem->function(ccitem->arg, ccitem->id, 0);
721-
}
722-
723-
for (i = 0; i < relcache_callback_count; i++)
724-
{
725-
struct RELCACHECALLBACK *ccitem = relcache_callback_list + i;
726-
727-
ccitem->function(ccitem->arg, InvalidOid);
728-
}
729-
}
730-
731-
732-
/* ----------------------------------------------------------------
733-
* public functions
734-
* ----------------------------------------------------------------
735-
*/
736-
737798
/*
738799
* AcceptInvalidationMessages
739800
* Read and process invalidation messages from the shared invalidation
@@ -787,68 +848,6 @@ AcceptInvalidationMessages(void)
787848
#endif
788849
}
789850

790-
/*
791-
* PrepareInvalidationState
792-
* Initialize inval data for the current (sub)transaction.
793-
*/
794-
static void
795-
PrepareInvalidationState(void)
796-
{
797-
TransInvalidationInfo *myInfo;
798-
799-
if (transInvalInfo != NULL &&
800-
transInvalInfo->my_level == GetCurrentTransactionNestLevel())
801-
return;
802-
803-
myInfo = (TransInvalidationInfo *)
804-
MemoryContextAllocZero(TopTransactionContext,
805-
sizeof(TransInvalidationInfo));
806-
myInfo->parent = transInvalInfo;
807-
myInfo->my_level = GetCurrentTransactionNestLevel();
808-
809-
/* Now, do we have a previous stack entry? */
810-
if (transInvalInfo != NULL)
811-
{
812-
/* Yes; this one should be for a deeper nesting level. */
813-
Assert(myInfo->my_level > transInvalInfo->my_level);
814-
815-
/*
816-
* The parent (sub)transaction must not have any current (i.e.,
817-
* not-yet-locally-processed) messages. If it did, we'd have a
818-
* semantic problem: the new subtransaction presumably ought not be
819-
* able to see those events yet, but since the CommandCounter is
820-
* linear, that can't work once the subtransaction advances the
821-
* counter. This is a convenient place to check for that, as well as
822-
* being important to keep management of the message arrays simple.
823-
*/
824-
if (NumMessagesInGroup(&transInvalInfo->CurrentCmdInvalidMsgs) != 0)
825-
elog(ERROR, "cannot start a subtransaction when there are unprocessed inval messages");
826-
827-
/*
828-
* MemoryContextAllocZero set firstmsg = nextmsg = 0 in each group,
829-
* which is fine for the first (sub)transaction, but otherwise we need
830-
* to update them to follow whatever is already in the arrays.
831-
*/
832-
SetGroupToFollow(&myInfo->PriorCmdInvalidMsgs,
833-
&transInvalInfo->CurrentCmdInvalidMsgs);
834-
SetGroupToFollow(&myInfo->CurrentCmdInvalidMsgs,
835-
&myInfo->PriorCmdInvalidMsgs);
836-
}
837-
else
838-
{
839-
/*
840-
* Here, we need only clear any array pointers left over from a prior
841-
* transaction.
842-
*/
843-
InvalMessageArrays[CatCacheMsgs].msgs = NULL;
844-
InvalMessageArrays[CatCacheMsgs].maxmsgs = 0;
845-
InvalMessageArrays[RelCacheMsgs].msgs = NULL;
846-
InvalMessageArrays[RelCacheMsgs].maxmsgs = 0;
847-
}
848-
849-
transInvalInfo = myInfo;
850-
}
851-
852851
/*
853852
* PostPrepare_Inval
854853
* Clean up after successful PREPARE.

0 commit comments

Comments
 (0)
0