diff options
| author | Noah Misch <noah@leadboat.com> | 2020-08-15 10:15:53 -0700 |
|---|---|---|
| committer | Noah Misch <noah@leadboat.com> | 2020-08-15 10:15:57 -0700 |
| commit | d4031d78460cbbb4ed2fb7be635f84bea0e9a0c1 (patch) | |
| tree | d7ee345e4522f52d62b51f33db15d96ba9a8535a /src/backend/utils/adt/tsquery_gist.c | |
| parent | 9d472b51e98777102d72f8ccdfb8cef10e087f74 (diff) | |
| download | postgresql-d4031d78460cbbb4ed2fb7be635f84bea0e9a0c1.tar.gz postgresql-d4031d78460cbbb4ed2fb7be635f84bea0e9a0c1.zip | |
Prevent concurrent SimpleLruTruncate() for any given SLRU.
The SimpleLruTruncate() header comment states the new coding rule. To
achieve this, add locktype "frozenid" and two LWLocks. This closes a
rare opportunity for data loss, which manifested as "apparent
wraparound" or "could not access status of transaction" errors. Data
loss is more likely in pg_multixact, due to released branches' thin
margin between multiStopLimit and multiWrapLimit. If a user's physical
replication primary logged ": apparent wraparound" messages, the user
should rebuild standbys of that primary regardless of symptoms. At less
risk is a cluster having emitted "not accepting commands" errors or
"must be vacuumed" warnings at some point. One can test a cluster for
this data loss by running VACUUM FREEZE in every database. Back-patch
to 9.5 (all supported versions).
Discussion: https://postgr.es/m/20190218073103.GA1434723@rfd.leadboat.com
Diffstat (limited to 'src/backend/utils/adt/tsquery_gist.c')
0 files changed, 0 insertions, 0 deletions