Date: Wed, 28 Feb 2018 19:56:43 -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: <20180228225643.trwxqmovq4uflf4f@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20180228212401.6yoqyv2a45zv7ph6@alap3.anarazel.de>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk

Andres Freund wrote:

> Alvaro,
> 
> On 2018-02-28 21:17:08 +0000, Alexandre Garcia wrote:
> > Oh yes sorry => `ERROR:  cannot freeze committed xmax 43076385` on that
> > same table
> 
> In light of
> Latest checkpoint's NextXID:          0/128653693
> I find this confusing.

Ooh.

If you SELECT FOR UPDATE a tuple in 9.2, bit 0x0040 gets set in
infomask, and nothing else.  If you pg_upgrade and later try to freeze
such a tuple, it will fail with the error reported.

The correct test to use is HEAP_XMAX_IS_LOCKED_ONLY, which also tests
for the above condition.

I will verify this theory and push a patch shortly, if it proves
correct.

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