aboutsummaryrefslogtreecommitdiff
path: root/src/tutorial/complex.source
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-07-13 11:52:50 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-07-13 11:53:12 -0400
commitf1963a1e79a499c2cf362fa41206a3b9e4348a54 (patch)
treeda2524abdfbe96e3d23c5f4e09b09333225336b6 /src/tutorial/complex.source
parentc81e49bd0fd6fe10b082ca27ea1158ea01fae0d3 (diff)
downloadpostgresql-f1963a1e79a499c2cf362fa41206a3b9e4348a54.tar.gz
postgresql-f1963a1e79a499c2cf362fa41206a3b9e4348a54.zip
Fix inadequate buffer locking in FSM and VM page re-initialization.
When reading an existing FSM or VM page that was found to be corrupt by the buffer manager, the code applied PageInit() to reinitialize the page, but did so without any locking. There is thus a hazard that two backends might concurrently do PageInit, which in itself would still be OK, but the slower one might then zero over subsequent data changes applied by the faster one. Even that is unlikely to be fatal; but it's not desirable, so add locking to prevent it. This does not add any locking overhead in the normal code path where the page is OK. It's not immediately obvious that that's safe, but I believe it is, for reasons explained in the added comments. Problem noted by R P Asim. It's been like this for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/CANXE4Te4G0TGq6cr0-TvwP0H4BNiK_-hB5gHe8mF+nz0mcYfMQ@mail.gmail.com
Diffstat (limited to 'src/tutorial/complex.source')
0 files changed, 0 insertions, 0 deletions