Re: [HACKERS] ARC buffer strategy committed

Jan Wieck <[EMAIL PROTECTED]> writes: > Yeah, adding a buffer multiple times to the list of unused buffers > ensures that it later on gets used for multiple contents simultaneously. Hm. Looking at the patch last night, I was wondering why you had removed all the guard logic from BufTableInsert

Re: [HACKERS] ARC buffer strategy committed

Tom Lane wrote: Jan Wieck <[EMAIL PROTECTED]> writes: Yeah, adding a buffer multiple times to the list of unused buffers ensures that it later on gets used for multiple contents simultaneously. Hm. Looking at the patch last night, I was wondering why you had removed all the guard logic from BufT

Re: [HACKERS] ARC buffer strategy committed

Jan Wieck wrote: Tom Lane wrote: Jan Wieck <[EMAIL PROTECTED]> writes: That's strange, if I reverse apply my patch I have buffer leak's and all kinds of crap. Can't even initdb. Who else applied patches tonight? FWIW, I can initdb --- that seems fine --- but the regression tests spew lots of smal

Re: [HACKERS] ARC buffer strategy committed

Jan Wieck <[EMAIL PROTECTED]> writes: > This all has changed. The freelist in ARC really contains clean and > unused buffers. I think I should write up a README.freelist explaining > the new bufmgr<->strategy interface and how the algorithm works. Yes, I was going to complain about the lack of a

Re: [HACKERS] ARC buffer strategy committed

Tom Lane wrote: Jan Wieck <[EMAIL PROTECTED]> writes: That's strange, if I reverse apply my patch I have buffer leak's and all kinds of crap. Can't even initdb. Who else applied patches tonight? FWIW, I can initdb --- that seems fine --- but the regression tests spew lots of small fragments. What

Re: [HACKERS] ARC buffer strategy committed

Jan Wieck <[EMAIL PROTECTED]> writes: > Can't even initdb. Who else applied patches tonight? FWIW, I did "make distclean", full rebuild, initdb on both HP and Linux machines. The HP passes both serial and parallel regression tests. The Linux machine initdb's, and simple manual queries seem to wor

Re: [HACKERS] ARC buffer strategy committed

Jan Wieck <[EMAIL PROTECTED]> writes: > That's strange, if I reverse apply my patch I have buffer leak's and all > kinds of crap. Can't even initdb. Who else applied patches tonight? FWIW, I can initdb --- that seems fine --- but the regression tests spew lots of small fragments. What I suspect

Re: [HACKERS] ARC buffer strategy committed

Jan Wieck <[EMAIL PROTECTED]> writes: > That's strange, if I reverse apply my patch I have buffer leak's and all > kinds of crap. Can't even initdb. Who else applied patches tonight? Well, there was my operator-class patch (which went nowhere near the buffer stuff) and also the initdb-in-C code (

Re: [HACKERS] ARC buffer strategy committed

Jan Wieck wrote: Tom Lane wrote: Jan Wieck <[EMAIL PROTECTED]> writes: I have just committed the implementation of ARC into the 7.5devel tree. I'm seeing a whole bunch of regression test failures that weren't there half an hour ago ... regards, tom lane Oh ... hmmm ... will check That's strang

Re: [HACKERS] ARC buffer strategy committed

Tom Lane wrote: Jan Wieck <[EMAIL PROTECTED]> writes: I have just committed the implementation of ARC into the 7.5devel tree. I'm seeing a whole bunch of regression test failures that weren't there half an hour ago ... regards, tom lane Oh ... hmmm ... will check Jan -- #=

Re: [HACKERS] ARC buffer strategy committed

Jan Wieck <[EMAIL PROTECTED]> writes: > I have just committed the implementation of ARC into the 7.5devel tree. I'm seeing a whole bunch of regression test failures that weren't there half an hour ago ... regards, tom lane ---(end of broadcast)

[HACKERS] ARC buffer strategy committed

I have just committed the implementation of ARC into the 7.5devel tree. This doesn't contain the vacuum page delay, or the test implementation of the background writer based on the checkpoint process. These two need some more discussion and bouncing around. Jan -- #