pgsql: Redefine HEAP_XMAX_IS_LOCKED_ONLY

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(-)

Browse pgsql-committers by date

  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