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 introducin
Good analysis. I guess the question is what patch would we put into a
subrelease? If you go for a new state code, rather than a separate
boolean, does it reduce the size of the patch?
---
Tom Lane wrote:
> I wrote:
> > OK,
Bruce Momjian 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 of broadcast)-
Tom Lane wrote:
> Bruce Momjian 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 ...
Well, then what real options do we have? It seems the patch is just
re
Bruce Momjian 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
SimpleLruWritePage. What's indete
I have applied a more limited patch that mentions this. I do not want
to mention _why_ we do not implement it because it is partly performance
and partly complexity, I think, and some combinations make no sense,
like temporary primary and non-temp foreign.
---
Tom Lane wrote:
> Bruce Momjian 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
> Simp
Bruce Momjian 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 the way back, but t
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 rea
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.
---
Tom Lane wrote:
> I wrote:
> > I think it would be possible to fix it in a less inv
Bruce Momjian 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 fixes Jim's problem th
On Mon, 2005-10-31 at 02:46 +, Simon Riggs wrote:
> I've been working on some docs for Constraining Exclusion & Partitioning
> for some time now. Deadlines seem to be looming, or may even have
> passed, so it seems sensible to submit what I have now.
> Many thanks to Josh Berkus for providing
On Mon, 2005-31-10 at 22:41 +, Simon Riggs wrote:
> I believe this is now complete and ready for application.
The changes need a fair bit of copy editing and SGML policy work, but
that is probably easier to do once it has been applied. Barring any
objections I'll apply the patch within 24 hour
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2005-31-10 at 22:41 +, Simon Riggs wrote:
>> I believe this is now complete and ready for application.
> The changes need a fair bit of copy editing and SGML policy work, but
> that is probably easier to do once it has been applied. Barring any
On Mon, 2005-31-10 at 23:15 -0500, Tom Lane wrote:
> I'd argue for editing first and then applying. I'll take up the job
> if you don't have time for the editing part
Okay. I'll do a round of copy editing and then commit to CVS -- there
will likely be room for additional improvements, so once it
On Mon, 2005-10-31 at 23:27 -0500, Neil Conway wrote:
> On Mon, 2005-31-10 at 23:15 -0500, Tom Lane wrote:
> > I'd argue for editing first and then applying. I'll take up the job
> > if you don't have time for the editing part
>
> Okay. I'll do a round of copy editing and then commit to CVS -- t
16 matches
Mail list logo
