Date: Thu, 1 Mar 2018 14:40:10 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andres Freund <andres@anarazel.de>
Cc: Alexandre Garcia <alexandre@vmfarms.com>,
	"pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: postgresql 9.6 - cannot freeze committed xmax
Message-ID: <20180301174010.vqrjlps5stz6opzd@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20180228234944.hjastb2mqr7rdnw5@alap3.anarazel.de>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk

Andres Freund wrote:

> Wonder if this a big enough fix? Isn't the bug "one layer up"? We
> shouldn't do the TransactionIdPrecedes() calls in the surrounding block,
> in the first place, right? Right now we could very well hit both
> ERROR: found xmax %u from before relfrozenxid %u
> and
> ERROR: cannot freeze committed xmax %u
> and freeze_xmax, totally_frozen will be wrong.  I think that's largely
> harmless, but we should fix it nonetheless, and inspect other relevant
> sites.

Hmm ...

After reading the 9.2 code, I don't think so.  These values must
absolutely be still within the freeze limits.  The version pre-pgupgrade
should have replaced the xmax with InvalidTransactionId as soon as the
tuple was freezable.

In fact, I checked 9.2's code and heap_tuple_needs_freeze tests "if xmax
not a multi and < cutoff_xid"; and in that case heap_freeze_tuple does
change the value to 0.

I hope I'm not misunderstanding what you mean.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services