eeeh... buffer leak?

Started by Lennert Buytenhekover 25 years ago5 messagesbugs
Jump to latest
#1Lennert Buytenhek
buytenh@gnu.org

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=#

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Lennert Buytenhek (#1)
Re: eeeh... buffer leak?

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

#3Lennert Buytenhek
buytenh@gnu.org
In reply to: Tom Lane (#2)
Re: eeeh... buffer leak?

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

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Lennert Buytenhek (#3)
Re: eeeh... buffer leak?

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

#5Lennert Buytenhek
buytenh@gnu.org
In reply to: Tom Lane (#4)
Re: eeeh... buffer leak?

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