On Thu, Mar 22, 2012 at 6:58 AM, Robert Haas
<robertmhaas@gmail.com> wrote:
On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane <
tgl@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.
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.
Thanks,
Pavan