Skip site navigation (1) Skip section navigation (2)

Re: advancing snapshot's xmin

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: advancing snapshot's xmin
Date: 2008-03-28 15:25:03
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>>>> As far as I can see, for the purposes of VACUUM we can remove any tuple
>>>> that was deleted after the old transaction's Xid but before that
>>>> transaction's Xmin (i.e. all of its live snapshots).  This means we get
>>>> to ignore Xid in GetOldestXmin and in the TransactionXmin calculations
>>>> in GetSnapshotData.  It would not surprise me, however, to find out that
>>>> I am overlooking something and this is incorrect.
>>> This seems entirely off-base to me.  In particular, if a transaction
>>> has an XID then its XMIN will never be greater than that, so I don't
>>> even see how you figure the case will arise.
>> My point exactly -- can we let the Xmin go past its Xid?  You imply we
>> can't, but why?
> Everything < xmin is considered to be not running anymore. Other  
> transactions would consider the still-alive transaction as aborted, and  
> start setting hint bits etc.

Okay.  So let's say we invent another TransactionId counter -- we keep
Xmin for the current purposes, and the other counter keeps track of
snapshots ignoring Xid.  This new counter could be used by VACUUM to
trim dead tuples.

Alvaro Herrera                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


pgsql-hackers by date

Next:From: Chris BrowneDate: 2008-03-28 15:33:42
Subject: Re: Transaction Snapshot Cloning
Previous:From: Heikki LinnakangasDate: 2008-03-28 15:22:25
Subject: Re: Prereading using posix_fadvise (was Re: Commitfest patches)

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group