On Thu, Mar 22, 2012 at 6:58 AM, Robert Haas <robertmh...@gmail.com> wrote:

> On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> It strikes me that it likely wouldn't be any
> >> worse than, oh, say, flipping the default value of
> >> standard_conforming_strings,
> >
> > Really?  It's taking away functionality and not supplying any substitute
> > (or at least you did not propose any).  In fact, you didn't even suggest
> > exactly how you propose to not break joined UPDATE/DELETE.
> Oh, hmm, interesting.  I had been thinking that you were talking about
> a case where *user code* was relying on the semantics of the TID,
> which has always struck me as an implementation detail that users
> probably shouldn't get too attached to.  But now I see that you're
> talking about something much more basic - the fundamental
> implementation of UPDATE and DELETE relies on the TID not changing
> under them.  That pretty much kills this idea dead in the water.
IIRC in early versions of HOT, I tried to swap the TIDs of newer versions
with the older version to handle this problem, but soon realized that it
might turn out too tricky and error-prone. The UPDATE/DELETE problem and
any other piece of code that works with TIDs and cache them across buffer
lock/unlock could face the issue. But it will be worthwhile to revisit the
issue and see if there is some easy way to reclaim those redirect line
pointers. If the HOT chain does not become dead, there will always to that
overhead of additional line pointer.


Reply via email to