I would like to give more details of my patch.
In postgres, it uses a global snapshot “CatalogSnapshot” to check catalog data visibility.
“CatalogSnapshot” is always updated to the latest version to make the latest catalog table
content visible.
If there is any updating on catalog tables, to make the changes to be visible for the following
commands in the current transaction,
“CommandCounterIncrement”-
>”AtCCI_LocalCache”
->”CommandEndInvalidationMessages
”->”LocalExecuteInvalidationMessage”
->”InvalidateCatalogSnapshot”
it will invalidate the “CatalogSnapshot” by setting it to NULL. And next time, when it needs the
“CatalogSnapsthot” and finds it is NULL, it will regenerate one.
In a query, “CommandCounterIncrement” may be called many times, and “CatalogSnapsthot” may be
destroyed and recreated many times. To reduce such overhead, instead of invalidating “CatalogSnapshot”
, we can keep it and just increase the “curcid” of it.
When the transaction is committed or aborted, or there are catalog invalidation messages from other
backends, the “CatalogSnapshot” will be invalidated and regenerated. Sometimes, the “CatalogSnapshot” is
not the same as the transaction “CurrentSnapshot”, but we can still update the CatalogSnapshot’s
“curcid”, as the “curcid” only be checked when the tuple is inserted or deleted by the current transaction.
