aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2021-06-21 05:13:46 -0700
committerAndres Freund <andres@anarazel.de>2021-06-21 05:13:46 -0700
commit5a1e1d83022b976ebdec5cfa8f255c4278b75b8e (patch)
tree83b9d8a46d2c28450ded5a1631e0d50200ff6ce9 /src/backend/access/gist
parent8d29d45d9b3cab95a866efbcdd9138b3d76741b3 (diff)
downloadpostgresql-5a1e1d83022b976ebdec5cfa8f255c4278b75b8e.tar.gz
postgresql-5a1e1d83022b976ebdec5cfa8f255c4278b75b8e.zip
Use correct horizon when vacuuming catalog relations.
In dc7420c2c92 I (Andres) accidentally used RelationIsAccessibleInLogicalDecoding() as the sole condition to use the non-shared catalog horizon in GetOldestNonRemovableTransactionId(). That is incorrect, as RelationIsAccessibleInLogicalDecoding() checks whether wal_level is logical. The correct check, as done e.g. in GlobalVisTestFor(), is to check IsCatalogRelation() and RelationIsAccessibleInLogicalDecoding(). The observed misbehavior of this bug was that there could be an endless loop in lazy_scan_prune(), because the horizons used in heap_page_prune() and the individual tuple liveliness checks did not match. Likely there are other potential consequences as well. A later commit will unify the determination which horizon has to be used, and add additional assertions to make it easier to catch a bug like this. Reported-By: Justin Pryzby <pryzby@telsasoft.com> Diagnosed-By: Matthias van de Meent <boekewurm+postgres@gmail.com> Author: Matthias van de Meent <boekewurm+postgres@gmail.com> Discussion: https://postgr.es/m/CAEze2Wg32Y9+WJfw=aofkRx1ZRFt_Ev6bNPc4PSaz7PjSFtZgQ@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist')
0 files changed, 0 insertions, 0 deletions