Date: Tue, 8 Mar 2011 00:38:08 -0800
From: daveg <daveg@sonic.net>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Greg Stark <gsstark@mit.edu>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Re: PD_ALL_VISIBLE flag was incorrectly set happend during
	repeatable vacuum
Message-ID: <20110308083808.GD21941@sonic.net>
References: <1B3CCBDD-4AC6-404A-9E26-DB4CA2554228@endpoint.com>
	<AANLkTi=xq4SV6jwA7txvrbEWocyeiU6XiTG=-zVy+7Dq@mail.gmail.com>
	<AANLkTi=Ye7AoF7_uVQfPVn-ok2VOp65mi0xU3H7kCke3@mail.gmail.com>
	<20110303071208.GA4053@sonic.net>
	<4D6F4E5D.6080507@enterprisedb.com>
	<20110304090031.GE4053@sonic.net>
	<4D710ABD.5090103@enterprisedb.com>
	<20110307235340.GA21941@sonic.net>
	<AANLkTi=54GF1MJN3FSXL2gr9xG_aB09y_taT8daUwz4Z@mail.gmail.com>
	<4D75E201.20402@enterprisedb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4D75E201.20402@enterprisedb.com>
User-Agent: Mutt/1.4.2.3i

On Tue, Mar 08, 2011 at 10:00:01AM +0200, Heikki Linnakangas wrote:
> On 08.03.2011 04:07, Greg Stark wrote:
> >Well from that log you definitely have OldestXmin going backwards. And
> >not by a little bit either. at 6:33 it set the all_visible flag and
> >then at 7:01 it was almost 1.3 million transactions earlier. In fact
> >to precisely the same value that was in use for a transaction at 1:38.
> >That seems like a bit of a coincidence though it's not repeated
> >earlier.
> 
> Yep. After staring at GetOldestXmin() again, it finally struck me how 
> OldestXmin can move backwards. You need two databases for it, which 
> probably explains why this has been so elusive.
... 
> What there are no other transactions active in the same database, 
> GetOldestXmin() returns just latestCompletedXid. When you open a 
> transaction in the same database after that, its xid will be above 
> latestCompletedXid, but its xmin includes transactions from all 
> databases, and there might be a transaction in some other database with 
> an xid that precedes the value that GetOldestXmin() returned earlier.
> 
> I'm not sure what to do about that. One idea is track two xmin values in 
> proc-array, one that includes transactions in all databases, and another 
> that only includes transactions in the same database. GetOldestXmin() 
> (when allDbs is false) would only pay attention to the latter. It would 
> add a few instructions to GetSnapshotData(), though.
> 
> Another idea is to give up on the warning when it appears that 
> oldestxmin has moved backwards, and assume that it's actually fine. We 
> could still warn in other cases where the flag appears to be incorrectly 
> set, like if there is a deleted tuple on the page.

I read this to mean that it is safe to ignore this warning and that these
databases are not at risk for data corruption or wrong results so long as
the warning is due to oldestxmin.  Please correct me if I have misunderstood. 

Thanks

-dg

-- 
David Gould       daveg@sonic.net      510 536 1443    510 282 0869
If simplicity worked, the world would be overrun with insects.