From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Fix inadequate buffer locking in FSM and VM page re-initializati |
Date: | 2018-07-13 15:53:33 |
Message-ID: | E1fe0Nx-000246-6U@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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
Branch
------
REL_11_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/5586e42b349346df5d88f71a5a41d8cb76b8c491
Modified Files
--------------
src/backend/access/heap/visibilitymap.c | 21 ++++++++++++++++++++-
src/backend/storage/freespace/freespace.c | 21 ++++++++++++++++++++-
2 files changed, 40 insertions(+), 2 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2018-07-13 16:57:01 | pgsql: Improve performance of tuple conversion map generation |
Previous Message | Bruce Momjian | 2018-07-13 15:17:12 | pgsql: docs: Remove "New" description of the libpqxx interface |