I have attached a more comprehensive MSWIN FAQ patch. Basically, the
instructions were way out of date and incorrect. Installing Postgres
from Cygwin is easier these days than the FAQ would imply.
This patch already includes Andrew's previous patch.
Chris
Andrew Dunstan wrote:
Tom Lane wr
Neil Conway wrote:
This patch cleans up some of the bufmgr code:
- replace uses of
LockBuffer(buf, BUFFER_LOCK_UNLOCK);
ReleaseBuffer(buf);
with the equivalent, but more concise:
UnlockAndReleaseBuffer(buf);
- analogous changes were made by replacing LockBuffer() + W
Currently, equal() does the following for List nodes:
case T_List:
{
List *la = (List *) a;
List *lb = (List *) b;
List *l;
/*
* Try to reject by length check before we grovel through
* all the elements...
*/
if
Jan Wieck <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> This patch cleans up some of the bufmgr code:
> Can this be held off a little while we're experimenting with
> improvements to the buffer algorithms?
I do not actually agree with the "UnlockAndReleaseBuffer" changes
anyway. I think t
Neil Conway <[EMAIL PROTECTED]> writes:
> This code is inefficient, however: length() requires iterating through
> the entire list, so this code scans both lists twice. The attached patch
> improves this by implementing equal() with a single scan of both lists.
You have effectively reverted the co
On Mon, 2003-11-03 at 10:04, Tom Lane wrote:
> You have effectively reverted the code to its previous slow state.
Erm, the original version of this code in CVS (from ~7 years ago) is the
following:
case T_List:
{
List *la = (List*)a;
List *lb = (List*)b;
On Mon, 2003-11-03 at 10:00, Tom Lane wrote:
> I do not actually agree with the "UnlockAndReleaseBuffer" changes
> anyway. I think this obscures the code by making resource grabbing
> and resource releasing code unsymmetrical
Hmm... fair enough, I see your point. In that case, should I remove the
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2003-11-03 at 10:04, Tom Lane wrote:
>> You have effectively reverted the code to its previous slow state.
> Erm, the original version of this code in CVS (from ~7 years ago) is the
> following:
Hm. I coulda sworn that at some point I changed tha
On Mon, 2003-11-03 at 16:39, Tom Lane wrote:
> The point is that the elements of the lists could be large, complicated
> structures that will take noticeable amounts of time to compare.
Good point, I agree with your analysis. At the very least, I'll add a
comment to equal() explaining why the algo
--On Monday, November 03, 2003 23:24:19 +0100 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
Larry Rosenman writes:
> I'll try and write the patch as you suggest.
Here's a patch as you suggested:
Isn't there a way to write a test that actually triggers the bug we're
trying to work around?
Not tha
Larry Rosenman writes:
> > I'll try and write the patch as you suggest.
> Here's a patch as you suggested:
Isn't there a way to write a test that actually triggers the bug we're
trying to work around?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
--On Monday, November 03, 2003 23:24:19 +0100 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
Larry Rosenman writes:
> I'll try and write the patch as you suggest.
Here's a patch as you suggested:
Isn't there a way to write a test that actually triggers the bug we're
trying to work around?
Here is
Neil Conway <[EMAIL PROTECTED]> writes:
> Do you think it would be worth the trouble to use both algorithms, and
> then test on the node tag of the first element to decide which one to
> use? (The assumption being lists are homogeneous).
Hard to tell. Since I haven't seen any evidence that equal(
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2003-11-03 at 10:00, Tom Lane wrote:
>> I do not actually agree with the "UnlockAndReleaseBuffer" changes
>> anyway. I think this obscures the code by making resource grabbing
>> and resource releasing code unsymmetrical
> Hmm... fair enough, I se
On Mon, 2003-11-03 at 18:19, Tom Lane wrote:
> Hard to tell. Since I haven't seen any evidence that equal() on lists
> is a particular hotspot, I'd lean against adding complexity and
> maintenance burden here.
Ok, I agree -- probably not worth doing, then.
> I have already done something much li
15 matches
Mail list logo
