aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeSetOp.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-05-24 15:20:12 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-05-24 15:20:36 -0400
commit996d273978c6f21b8b66f7f3bdd979cc37736c7a (patch)
tree1ed83bb05d282ccb28cc1a4e63a7a5fc3c6bf299 /src/backend/executor/nodeSetOp.c
parent0c7cd45b6d702253c09427929bcceb6e7fe9029a (diff)
downloadpostgresql-996d273978c6f21b8b66f7f3bdd979cc37736c7a.tar.gz
postgresql-996d273978c6f21b8b66f7f3bdd979cc37736c7a.zip
Avoid consuming an XID during vac_truncate_clog().
vac_truncate_clog() uses its own transaction ID as the comparison point in a sanity check that no database's datfrozenxid has already wrapped around "into the future". That was probably fine when written, but in a lazy vacuum we won't have assigned an XID, so calling GetCurrentTransactionId() causes an XID to be assigned when otherwise one would not be. Most of the time that's not a big problem ... but if we are hard up against the wraparound limit, consuming XIDs during antiwraparound vacuums is a very bad thing. Instead, use ReadNewTransactionId(), which not only avoids this problem but is in itself a better comparison point to test whether wraparound has already occurred. Report and patch by Alexander Korotkov. Back-patch to all versions. Report: <CAPpHfdspOkmiQsxh-UZw2chM6dRMwXAJGEmmbmqYR=yvM7-s6A@mail.gmail.com>
Diffstat (limited to 'src/backend/executor/nodeSetOp.c')
0 files changed, 0 insertions, 0 deletions