Re: HOT updates & REDIRECT line pointers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: HOT updates & REDIRECT line pointers
Date: 2012-03-22 00:09:48
Message-ID: 12659.1332374988@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Specifically, I'm wondering if we couldn't get away with rearranging
> things so that the root line pointer (which has index entries) points
> to the actual tuple, and the other line pointer (which can't have any
> index entries) gets marked UNUSED.

This would amount to changing the TID of the live row. In the past we
have considered that that can only be allowed when holding an exclusive
lock on the table (a la old-style VACUUM FULL). An example of the sort
of situation where it'd be dangerous is an UPDATE involving a join,
which might read a tuple-to-be-updated (including its TID), then release
pin on that page for awhile while going about its business with the
join, and eventually expect to come back and find the tuple still at the
same TID. I believe there are applications that similarly expect a TID
that they've fetched to remain valid for as long as they're holding some
type of lock on the table or row.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-03-22 00:13:32 Re: HOT updates & REDIRECT line pointers
Previous Message Greg Stark 2012-03-21 23:49:43 Re: Proposal: Create index on foreign table