Re: [HACKERS] Review: compact fsync request queue on overflow

2011-01-21 Thread Chris Browne
robertmh...@gmail.com (Robert Haas) writes: > On Mon, Jan 17, 2011 at 8:23 PM, Greg Smith wrote: >> Quite.  It's taken me 12 days of machine time running pgbench to find the >> spots where this problem occurs on a system with a reasonably sized >> shared_buffers (I'm testing against 256MB).  It's

Re: [HACKERS] Review: compact fsync request queue on overflow

2011-01-21 Thread Robert Haas
On Mon, Jan 17, 2011 at 8:23 PM, Greg Smith wrote: > Quite.  It's taken me 12 days of machine time running pgbench to find the > spots where this problem occurs on a system with a reasonably sized > shared_buffers (I'm testing against 256MB).  It's one of those things it's > hard to reproduce with

Re: [HACKERS] Review: compact fsync request queue on overflow

2011-01-17 Thread Greg Smith
Chris Browne wrote: It was a little troublesome inducing it. I did so by cutting shared memory to minimum (128kB)... With higher shared memory, I couldn't readily induce compaction, which is probably a concurrency matter of not having enough volume of concurrent wor

Re: [HACKERS] Review: compact fsync request queue on overflow

2011-01-17 Thread Robert Haas
On Mon, Jan 17, 2011 at 1:43 PM, Chris Browne wrote: >      (I observe that it wasn't all that obvious that "hash_search()" >      *adds* elements that are missing.  I got confused and went >      looking for "hash_add() or similar.  It's permissible to say "dumb >      Chris".) I didn't invent t

[HACKERS] Review: compact fsync request queue on overflow

2011-01-17 Thread Chris Browne
I have been taking a peek at the following commitfest item: https://commitfest.postgresql.org/action/patch_view?id=497 Submission: - I had to trim a little off the end of the patch to apply it, but that's likely the fault of how I cut'n'pasted it. It applied cleanly against HEAD. - I obse