From a21b7d531414db225da7016ae34949fb26435c7f Mon Sep 17 00:00:00 2001 From: Jozef Mlich Date: Thu, 13 Mar 2014 13:50:06 +0100 Subject: [PATCH] - Fix WAL replay of locking an updated tuple kudos to Alvaro Herrera See http://www.postgresql.org/message-id/CA+Tgmob8vfzYrLToqYr7uJ2moW3Gnv8rZpPtznxVXRPfTHQpCA@mail.gmail.com --- ...l-replay-of-locking-an-updated-tuple.patch | 46 +++++++++++++++++++ postgresql.spec | 8 +++- 2 files changed, 53 insertions(+), 1 deletion(-) create mode 100644 postgresql-wal-replay-of-locking-an-updated-tuple.patch diff --git a/postgresql-wal-replay-of-locking-an-updated-tuple.patch b/postgresql-wal-replay-of-locking-an-updated-tuple.patch new file mode 100644 index 0000000..592507c --- /dev/null +++ b/postgresql-wal-replay-of-locking-an-updated-tuple.patch @@ -0,0 +1,46 @@ +commit 9a57858f1103b89a5674f0d50c5fe1f756411df6 +Author: Alvaro Herrera +Date: Thu Feb 27 11:13:39 2014 -0300 + + Fix WAL replay of locking an updated tuple + + We were resetting the tuple's HEAP_HOT_UPDATED flag as well as t_ctid on + WAL replay of a tuple-lock operation, which is incorrect when the tuple + is already updated. + + Back-patch to 9.3. The clearing of both header elements was there + previously, but since no update could be present on a tuple that was + being locked, it was harmless. + + Bug reported by Peter Geoghegan and Greg Stark in + CAM3SWZTMQiCi5PV5OWHb+bYkUcnCk=O67w0cSswPvV7XfUcU5g@mail.gmail.com and + CAM-w4HPTOeMT4KP0OJK+mGgzgcTOtLRTvFZyvD0O4aH-7dxo3Q@mail.gmail.com + respectively; diagnosis by Andres Freund. + +diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c +index 33fc5a7..d94980b 100644 +--- a/src/backend/access/heap/heapam.c ++++ b/src/backend/access/heap/heapam.c +@@ -7721,11 +7721,19 @@ heap_xlog_lock(XLogRecPtr lsn, XLogRecord *record) + + fix_infomask_from_infobits(xlrec->infobits_set, &htup->t_infomask, + &htup->t_infomask2); +- HeapTupleHeaderClearHotUpdated(htup); ++ ++ /* ++ * Clear relevant update flags, but only if the modified infomask says ++ * there's no update. ++ */ ++ if (HEAP_XMAX_IS_LOCKED_ONLY(htup->t_infomask)) ++ { ++ HeapTupleHeaderClearHotUpdated(htup); ++ /* Make sure there is no forward chain link in t_ctid */ ++ htup->t_ctid = xlrec->target.tid; ++ } + HeapTupleHeaderSetXmax(htup, xlrec->locking_xid); + HeapTupleHeaderSetCmax(htup, FirstCommandId, false); +- /* Make sure there is no forward chain link in t_ctid */ +- htup->t_ctid = xlrec->target.tid; + PageSetLSN(page, lsn); + MarkBufferDirty(buffer); + UnlockReleaseBuffer(buffer); diff --git a/postgresql.spec b/postgresql.spec index d0c7829..6cf64db 100644 --- a/postgresql.spec +++ b/postgresql.spec @@ -64,7 +64,7 @@ Summary: PostgreSQL client programs Name: postgresql %global majorversion 9.3 Version: 9.3.3 -Release: 1%{?dist} +Release: 2%{?dist} # The PostgreSQL license is very similar to other MIT licenses, but the OSI # recognizes it as an independent license, so we do as well. @@ -108,6 +108,7 @@ Patch3: postgresql-perl-rpath.patch Patch4: postgresql-config-comment.patch Patch5: postgresql-var-run-socket.patch Patch6: postgresql-man.patch +Patch7: postgresql-wal-replay-of-locking-an-updated-tuple.patch BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex gawk help2man BuildRequires: perl(ExtUtils::Embed), perl-devel @@ -335,6 +336,7 @@ benchmarks. %patch4 -p1 %patch5 -p1 %patch6 -p1 +%patch7 -p1 # We used to run autoconf here, but there's no longer any real need to, # since Postgres ships with a reasonably modern configure script. @@ -1131,6 +1133,10 @@ fi %endif %changelog +* Thu Mar 13 2014 Jozef Mlich - 9.3.3-2 +- Fix WAL replay of locking an updated tuple + kudos to Alvaro Herrera + * Thu Feb 20 2014 Jozef Mlich - 9.3.3-1 - update to 9.3.3 minor version per release notes: http://www.postgresql.org/docs/9.3/static/release-9-3-3.html