From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Redefine HEAP_XMAX_IS_LOCKED_ONLY |
Date: | 2013-01-24 20:19:15 |
Message-ID: | E1TyTGV-0004Vf-15@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Redefine HEAP_XMAX_IS_LOCKED_ONLY
Tuples marked SELECT FOR UPDATE in a cluster that's later processed by
pg_upgrade would have a different infomask bit pattern than those
produced by 9.3dev; that bit pattern was being seen as "dead" by HEAD
(because they would fail the "is this tuple locked" test, and so the
visibility rules would thing they're updated, even though there's no
HEAP_UPDATED version of them). In other words, some rows could silently
disappear after pg_upgrade.
With this new definition, those tuples become visible again.
This is breakage resulting from my commit 0ac5ad5134.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/74ebba84aeb6b0e6320f9b992527715f7e2ace8e
Modified Files
--------------
src/include/access/htup_details.h | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-01-24 20:20:50 | pgsql: pg_upgrade: detect stale postmaster.pid lock files |
Previous Message | Noah Misch | 2013-01-24 18:07:54 | Re: Materialized views WIP patch |