Обсуждение: 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