Your branch is up to date with 'origin/page'.
Changes to be committed:
modified: rawpage.cpp
On branch page
Your branch is up to date with 'origin/page'.
Changes to be committed:
modified: rawpage.cpp
On branch page
Your branch is up to date with 'origin/page'.
Changes to be committed:
modified: rawpage.cpp
On branch page
Your branch is up to date with 'origin/page'.
Changes to be committed:
modified: rawpage.cpp
On branch page
Your branch is up to date with 'origin/page'.
Changes to be committed:
modified: catalog.cpp
On branch page
Your branch is up to date with 'origin/page'.
Changes to be committed:
modified: catalog.cpp
On branch page
Your branch is up to date with 'origin/page'.
Changes to be committed:
modified: catalog.cpp
On branch page
Your branch is up to date with 'origin/page'.
Changes to be committed:
modified: catalog.cpp
On branch page
Your branch is up to date with 'origin/page'.
Changes to be committed:
modified: contrib/pageinspect/rawpage.cpp
modified: src/common/backend/catalog/catalog.cpp
Usually, when a relation gets changed by a DB user, an invalidation
message is sent to the shared context. Plancache will revalidate
this behavior multiple times during the execution so that if the
base relation changes, the cached plan will be updated accordingly.
However, Postgres does not allow the resulting attributes to change
because changing the query's result on the fly requires extra hand-
ling on the user application, which is out of the DB kernel's
control. Also, it will generate unwanted behavior in a concurrent
transactional application.
Due to the user's heavy request, we are allowing this in this patch
and introduced a new POSTMASTER GUC to control this behavior. This
GUC is a POSTMASTER type because the result-checking behavior is a
flag (i.e., an intrinsic attribute) of the plan cache, initially
only for transactional statements. We need to ensure that when the
user changes the GUC, no plan cache is working at the time.
