Robert Haas writes:
> On Wed, Aug 17, 2011 at 1:10 PM, Tom Lane wrote:
>> The plpython patch Jan just submitted reminds me that several of the PLs
>> detect whether they have obsolete cached data by noting whether the
>> tuple's xmin *and* TID are the same as previously seen.
>> Can anyone think
On Wed, Aug 17, 2011 at 1:10 PM, Tom Lane wrote:
> BTW, while we're thinking about this ...
>
> The plpython patch Jan just submitted reminds me that several of the PLs
> detect whether they have obsolete cached data by noting whether the
> tuple's xmin *and* TID are the same as previously seen.
>
BTW, while we're thinking about this ...
The plpython patch Jan just submitted reminds me that several of the PLs
detect whether they have obsolete cached data by noting whether the
tuple's xmin *and* TID are the same as previously seen.
Unlike depending on TID alone, I think this is probably saf
Heikki Linnakangas writes:
> A callback might be using the tuple ID in a way that fails if VACUUM
> FULL moves the tuple, so I think we *have* to change it. (as you did
> already)
Yeah, I thought about that too. As things stand in 9.0 and 9.1, there's
at least a theoretical possibility of this
On Tue, Aug 16, 2011 at 10:17 PM, Tom Lane wrote:
> Any objections to that plan?
None at all, but some questions.
This overhaul of the cache mechanism has been extensive, so you're now
very well placed to answer related questions.
As you know, I've been trying to reduce the lock strength of so
On 17.08.2011 00:17, Tom Lane wrote:
I'm looking into the idea I mentioned earlier:
All is not entirely lost, however: there's still some possible
performance benefit to be gained here, if we go to the scheme of
identifying victim catcache entries by hashvalue only. Currently,
each heap_update
