Re: hot update doesn't work?

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: hot update doesn't work?
Date: 2010-05-12 15:55:35
Message-ID: 4BEACF77.9090707@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> The correct question to ask is whether we could
> vacuum away the older elements of the HOT chain on the grounds that they
> are no longer of interest. What we would see is tuples with xmin equal
> to xmax and cmin different from cmax. The problem then is to determine
> whether there are any live snapshots with curcid between cmin and cmax.
> There is 0 hope of doing that from outside the originating backend.
> Now if heap_page_prune() is being run by the same backend that generated
> the in-doubt tuples, which I will agree is likely in a case like this,
> in principle we could do it.

There's an extra hurdle in the way: If you remove tuples in the middle
of an update chain (not necessarily a HOT update chain), the latest
tuple becomes inaccessible to other transactions running in read
committed mode that might need to find the latest version of the row by
following the ctid pointers.

That's not an issue if the row was created in the same transaction too,
but we don't know that in HeapTupleSatisfiesVacuum.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2010-05-12 15:57:35 Re: hot update doesn't work?
Previous Message Tom Lane 2010-05-12 15:52:01 Re: [COMMITTERS] pgsql: Add PGFILEDESC description to Makefiles for all /contrib