aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2016-04-23 19:18:00 -0700
committerAndres Freund <andres@anarazel.de>2016-04-26 20:21:54 -0700
commitc6ff84b06a68b71719aa1aaa5f6704d8db1b51f8 (patch)
treebca1d7f785aa03f73b137f3182d028e16abdf519 /src/backend/executor
parent2ac3be2e763d9b971352819f285dd51519e0aeb9 (diff)
downloadpostgresql-c6ff84b06a68b71719aa1aaa5f6704d8db1b51f8.tar.gz
postgresql-c6ff84b06a68b71719aa1aaa5f6704d8db1b51f8.zip
Emit invalidations to standby for transactions without xid.
So far, when a transaction with pending invalidations, but without an assigned xid, committed, we simply ignored those invalidation messages. That's problematic, because those are actually sent for a reason. Known symptoms of this include that existing sessions on a hot-standby replica sometimes fail to notice new concurrently built indexes and visibility map updates. The solution is to WAL log such invalidations in transactions without an xid. We considered to alternatively force-assign an xid, but that'd be problematic for vacuum, which might be run in systems with few xids. Important: This adds a new WAL record, but as the patch has to be back-patched, we can't bump the WAL page magic. This means that standbys have to be updated before primaries; otherwise "PANIC: standby_redo: unknown op code 32" errors can be encountered. XXX: Reported-By: Васильев Дмитрий, Masahiko Sawada Discussion: CAB-SwXY6oH=9twBkXJtgR4UC1NqT-vpYAtxCseME62ADwyK5OA@mail.gmail.com CAD21AoDpZ6Xjg=gFrGPnSn4oTRRcwK1EBrWCq9OqOHuAcMMC=w@mail.gmail.com
Diffstat (limited to 'src/backend/executor')
0 files changed, 0 insertions, 0 deletions