Re: HOT WIP Patch - version 1

On 2/14/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> > What's the verdict on relaxing the "live tuple's ctid doesn't change
> > rule"?
>
> I think that's unacceptable; it is known that that will break the ODBC
> and JDBC drivers, as well as any other programs that make use of the
> ctid for re-finding a tuple they read earlier in the same transaction.
> We have not only never deprecated client-side use of ctid for this, but
> actively encouraged it, for instance by going out of our way to support
> fast access for queries "WHERE ctid = 'constant'".
>
> What's more, your proposal would break plain old UPDATE and DELETE,
> as well as SELECT FOR UPDATE, none of which promise to hold a pin
> continuously on every page containing a tuple they might decide to
> revisit (by ctid) later. Are you prepared to disallow hash join and
> sort/merge join in all such queries?

Not that I am suggesting we do this, but I believe we had some solution
to this problem in the earlier version of HOT. The live tuple when
copied-back
to the root tuple, the tuple is marked with a HEAP_COPIED_BACK flag.

HeapTupleSatisfiesUpdate() checks for this flag and if set returns a new
return code, HeapTupleCopiedBack. heap_update() returns the same
to ExecUpdate along with the ctid of the root tuple. The UPDATE/DELETE
operation then retried on the root tuple, very similar to read-committed
update/delete. The xmax of the copied-back tuple is set so that its
not vacuumed away until all the current transactions are completed.

Though I have tested this patch several times and it seems to work fine,
I probably don''t have insight into the code as much others on this list
has. So if someone wants to take a look and see if it would work fine,
I would be more than happy to post the latest HOT patch (older design).

Thanks,
Pavan

--

EnterpriseDB http://www.enterprisedb.com