mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-21 08:29:39 +08:00
Code Issues Packages Projects Releases Wiki Activity

Improve comment about handling of temp tables in shared-inval code.

Browse Source
This commit is contained in:
Tom Lane 2011-09-06 17:05:48 -04:00
parent e6d800981e
commit db10f01baa
1 changed files with 9 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
src/backend/utils/cache/inval.c vendored
View File

@ -75,6 +75,15 @@
* transaction but must be kept till top-level commit otherwise. For * transaction but must be kept till top-level commit otherwise. For
* simplicity we keep the controlling list-of-lists in TopTransactionContext. * simplicity we keep the controlling list-of-lists in TopTransactionContext.
* *
* Currently, inval messages are sent without regard for the possibility
* that the object described by the catalog tuple might be a session-local
* object such as a temporary table. This is because (1) this code has
* no practical way to tell the difference, and (2) it is not certain that
* other backends don't have catalog cache or even relcache entries for
* such tables, anyway; there is nothing that prevents that. It might be
* worth trying to avoid sending such inval traffic in the future, if those
* problems can be overcome cheaply.
*
* *
* Portions Copyright (c) 1996-2011, PostgreSQL Global Development Group * Portions Copyright (c) 1996-2011, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California * Portions Copyright (c) 1994, Regents of the University of California
@ -811,10 +820,6 @@ ProcessCommittedInvalidationMessages(SharedInvalidationMessage *msgs,
* since they'll not have seen our changed tuples anyway. We can forget * since they'll not have seen our changed tuples anyway. We can forget
* about CurrentCmdInvalidMsgs too, since those changes haven't touched * about CurrentCmdInvalidMsgs too, since those changes haven't touched
* the caches yet. * the caches yet.
*
* We still send invalidation messages for session-local objects to other
* backends because, while other backends cannot see any tuples, they can
* drop tables that are session-local to another session.
* *
* In any case, reset the various lists to empty. We need not physically * In any case, reset the various lists to empty. We need not physically
* free memory here, since TopTransactionContext is about to be emptied * free memory here, since TopTransactionContext is about to be emptied