- Fix WAL replay of locking an updated tuple
kudos to Alvaro Herrera See http://www.postgresql.org/message-id/CA+Tgmob8vfzYrLToqYr7uJ2moW3Gnv8rZpPtznxVXRPfTHQpCA@mail.gmail.com
This commit is contained in:
parent
a2f501b795
commit
a21b7d5314
46
postgresql-wal-replay-of-locking-an-updated-tuple.patch
Normal file
46
postgresql-wal-replay-of-locking-an-updated-tuple.patch
Normal file
@ -0,0 +1,46 @@
|
||||
commit 9a57858f1103b89a5674f0d50c5fe1f756411df6
|
||||
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
|
||||
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);
|
@ -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 <jmlich@redhat.com> - 9.3.3-2
|
||||
- Fix WAL replay of locking an updated tuple
|
||||
kudos to Alvaro Herrera
|
||||
|
||||
* Thu Feb 20 2014 Jozef Mlich <jmlich@redhat.com> - 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
|
||||
|
Loading…
Reference in New Issue
Block a user