Re: [HACKERS] PinBuffer() no longer makes use of strategy

2017-03-20 Thread Alexander Korotkov
On Mon, Mar 20, 2017 at 6:09 PM, Teodor Sigaev wrote: > if (buf->usage_count < BM_MAX_USAGE_COUNT) >> if (BUF_STATE_GET_USAGECOUNT(buf_state) != BM_MAX_USAGE_COUNT) >> >> being prone to paranoia, I prefer the first, but I've seen both >> styles in >> the

Re: [HACKERS] PinBuffer() no longer makes use of strategy

2017-03-20 Thread Teodor Sigaev
if (buf->usage_count < BM_MAX_USAGE_COUNT) if (BUF_STATE_GET_USAGECOUNT(buf_state) != BM_MAX_USAGE_COUNT) being prone to paranoia, I prefer the first, but I've seen both styles in the code so I don't know if it's worth futzing with. Ok, let's be paranoic and do this same

Re: [HACKERS] PinBuffer() no longer makes use of strategy

2017-03-20 Thread Alexander Korotkov
On Sun, Mar 19, 2017 at 3:51 AM, Jim Nasby wrote: > On 3/16/17 12:48 PM, David Steele wrote: > >> This patch looks pretty straight forward and applies cleanly and >> compiles at cccbdde. >> >> It's not a straight revert, though, so still seems to need review. >> >> Jim, do

Re: [HACKERS] PinBuffer() no longer makes use of strategy

2017-03-19 Thread Simon Riggs
On 4 February 2017 at 09:33, Andres Freund wrote: > For pretty much else that logic seems worse, > because it essentially prevents any buffers ever staying in s_b when > only ringbuffer accesses are performed. That was exactly its intent. The ringbuffer was designed to avoid

Re: [HACKERS] PinBuffer() no longer makes use of strategy

2017-03-18 Thread Jim Nasby
On 3/16/17 12:48 PM, David Steele wrote: This patch looks pretty straight forward and applies cleanly and compiles at cccbdde. It's not a straight revert, though, so still seems to need review. Jim, do you know when you'll have a chance to look at that? Yes. Compiles and passes for me as

Re: [HACKERS] PinBuffer() no longer makes use of strategy

2017-03-16 Thread David Steele
On 2/4/17 2:47 PM, Alexander Korotkov wrote: > On Sat, Feb 4, 2017 at 4:33 AM, Andres Freund > wrote: > > On 2017-02-03 19:13:45 -0600, Jim Nasby wrote: > > No, I noticed it while reading code. Removing that does mean that if any > >

Re: [HACKERS] PinBuffer() no longer makes use of strategy

2017-02-23 Thread Jim Nasby
On 2/4/17 1:47 PM, Alexander Korotkov wrote: I'm tempted to put the old logic back, but more because this likely was unintentional, not because I think it's clearly better. +1 Yes, it was unintentional change. So we should put old logic back unless we have proof that this change make

Re: [HACKERS] PinBuffer() no longer makes use of strategy

2017-02-04 Thread Alexander Korotkov
On Sat, Feb 4, 2017 at 4:33 AM, Andres Freund wrote: > On 2017-02-03 19:13:45 -0600, Jim Nasby wrote: > > No, I noticed it while reading code. Removing that does mean that if any > > non-default strategy (in any backend) hits that buffer again then the > buffer > > will

Re: [HACKERS] PinBuffer() no longer makes use of strategy

2017-02-03 Thread Andres Freund
Hi, On 2017-02-03 19:13:45 -0600, Jim Nasby wrote: > No, I noticed it while reading code. Removing that does mean that if any > non-default strategy (in any backend) hits that buffer again then the buffer > will almost certainly migrate into the main buffer pool the next time one of > the rings

Re: [HACKERS] PinBuffer() no longer makes use of strategy

2017-02-03 Thread Jim Nasby
On 2/3/17 6:39 PM, Andres Freund wrote: Hi, On 2017-02-03 18:32:03 -0600, Jim Nasby wrote: Commit 48354581a49c30f5757c203415aa8412d85b0f70 (Allow Pin/UnpinBuffer to operate in a lockfree manner) removed the code in PinBuffer that conditionally incremented usage_count when a ring buffer was in

Re: [HACKERS] PinBuffer() no longer makes use of strategy

2017-02-03 Thread Andres Freund
Hi, On 2017-02-03 18:32:03 -0600, Jim Nasby wrote: > Commit 48354581a49c30f5757c203415aa8412d85b0f70 (Allow Pin/UnpinBuffer to > operate in a lockfree manner) removed the code in PinBuffer that > conditionally incremented usage_count when a ring buffer was in use. Was > that intentional? ISTM the