I wrote:
OK, I think I see it. The problem is that the code in slru.c is careful
about not modifying state when it doesn't hold the proper lock, but not
so careful about not *inspecting* state without the proper lock.
...
I'm still thinking about how to make a real fix without introducing
Bruce Momjian pgman@candle.pha.pa.us writes:
If you go for a new state code, rather than a separate
boolean, does it reduce the size of the patch?
No, and it certainly wouldn't improve my level of confidence in it ...
regards, tom lane
---(end
Bruce Momjian pgman@candle.pha.pa.us writes:
Well, then what real options do we have? It seems the patch is just
required for all branches.
I think it would be possible to fix it in a less invasive way by taking
and releasing the ControlLock an extra time in SimpleLruReadPage and
Bruce Momjian pgman@candle.pha.pa.us writes:
To me a performance problem is much harder get reports on and to locate
than a real fix to the problem. I think if a few people eyeball the
patch, it is OK for application. Are backpatches significantly
different?
Well, the logic is the same all
I wrote:
I think it would be possible to fix it in a less invasive way by taking
and releasing the ControlLock an extra time in SimpleLruReadPage and
SimpleLruWritePage. What's indeterminate about that is the performance
cost.
Attached is an alternative patch that does it this way. I
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, this is the way to fix for 8.0 and earlier. It is up to you about
8.1. I think we can handle the larger patch if we do another RC.
Well, I'd like not to do another RC, so I'll hold the larger patch for
8.2.
We still need a test to confirm it
