Thread

1. eeeh... buffer leak?

   Lennert Buytenhek <buytenh@gnu.org> — 2000-10-16T00:55:38Z

   Hmmm... is this bad?
   
   
   ulsec=# truncate job;
   NOTICE:  Buffer Leak: [002] (freeNext=-3, freePrev=-3, relname=job, blockNum=0,
   flags=0xc, refcount=1 -1)
   TRUNCATE
   ulsec=#
   
   
   

2. Re: eeeh... buffer leak?

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-10-16T01:27:53Z

   Lennert Buytenhek <buytenh@gnu.org> writes:
   > ulsec=# truncate job;
   > NOTICE:  Buffer Leak: [002] (freeNext=-3, freePrev=-3, relname=job, blockNum=0,
   > flags=0xc, refcount=1 -1)
   > TRUNCATE
   
   Hmm, that's interesting.  It shouldn't be possible for PrivateRefCount
   (the last value printed) to become negative.  Can you give a sequence
   for reproducing this notice from a standing start?
   
   The notice isn't especially worrisome in itself, but to the extent that
   it implies some incorrect bookkeeping of buffer refcounts, there could
   be a problem lurking somewhere.
   
   			regards, tom lane
   
   

3. Re: eeeh... buffer leak?

   Lennert Buytenhek <buytenh@gnu.org> — 2000-10-16T21:55:34Z

   
   On Sun, 15 Oct 2000, Tom Lane wrote:
   
   > > ulsec=# truncate job;
   > > NOTICE:  Buffer Leak: [002] (freeNext=-3, freePrev=-3, relname=job, blockNum=0,
   > > flags=0xc, refcount=1 -1)
   > > TRUNCATE
   > 
   > Hmm, that's interesting.  It shouldn't be possible for PrivateRefCount
   > (the last value printed) to become negative.  Can you give a sequence
   > for reproducing this notice from a standing start?
   
   Unfortunately not. I was very very surprised when I saw this (as I never
   got any errors like this), and I tried to reproduce what I did, but I
   didn't get this message again. (This is a pretty heavily-used database
   (lots of clients via the network), so the odds of reproducing the exact
   sequence of events is pretty small anyway).
   
   By the way, this is PostgreSQL 7.0.2 on a Red Hat 6.2 box with a custom
   kernel.
   
   So.. what am I to do if I ever get this message again?
   
   
   
   greetings,
   Lennert
   
   
   

4. Re: eeeh... buffer leak?

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-10-17T04:21:13Z

   Lennert Buytenhek <buytenh@gnu.org> writes:
   >> Hmm, that's interesting.  It shouldn't be possible for PrivateRefCount
   >> (the last value printed) to become negative.  Can you give a sequence
   >> for reproducing this notice from a standing start?
   
   > Unfortunately not. I was very very surprised when I saw this (as I never
   > got any errors like this), and I tried to reproduce what I did, but I
   > didn't get this message again. (This is a pretty heavily-used database
   > (lots of clients via the network), so the odds of reproducing the exact
   > sequence of events is pretty small anyway).
   
   PrivateRefCount is local to a particular backend, so the behavior of
   other clients shouldn't matter (in theory anyway ;-)).  It should be
   sufficient to reproduce the sequence executed by your specific session.
   Not that that helps much if you don't remember, but please try.
   
   > So.. what am I to do if I ever get this message again?
   
   Don't panic ... but see if you can reproduce it.
   
   			regards, tom lane
   
   

5. Re: eeeh... buffer leak?

   Lennert Buytenhek <buytenh@gnu.org> — 2000-10-25T20:19:08Z

   
   On Tue, 17 Oct 2000, Tom Lane wrote:
   
   > PrivateRefCount is local to a particular backend, so the behavior of
   > other clients shouldn't matter (in theory anyway ;-)).  It should be
   > sufficient to reproduce the sequence executed by your specific session.
   > Not that that helps much if you don't remember, but please try.
   
   Sorry, I haven't come around this message anymore :(
   
   Could it have been caused by defective hardware?
   
   
   > > So.. what am I to do if I ever get this message again?
   > 
   > Don't panic ... but see if you can reproduce it.
   
   Heh.. just think Douglas Adams?
   
   
   greetings,
   Lennert