Thread: eeeh... buffer leak?
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=#
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
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
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
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
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