Robert Haas <robertmh...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
