Date: Thu, 1 Mar 2018 18:32:08 -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: <20180301213208.y7e4aflsklro4kpr@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20180301174010.vqrjlps5stz6opzd@alvherre.pgsql>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk

I pushed my proposed fix all the way back to 9.3.

As I said earlier, I couldn't detect a bug of the sort you describe:

a) as I argued in my previous email, no tuple earlier than the
   relfreezexid should survive, because 9.2 did remove those when
   freezing the table.

b) One thing we could do but do not, is detect the case where there is
   an Xmax that is newer than the cutoff_xid but comes from before the
   pg_upgrade.  We don't freeze it in that case.  But we do return it as
   totally_frozen=false, so it'll be frozen later anyway -- nothing bad
   happens.  I don't think this is worth tinkering with.

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