refcount leak warnings

Started by Thomas Hallgrenalmost 20 years ago3 messageshackers
Jump to latest
#1Thomas Hallgren
thhal@mailblocks.com

I have a PL/Java user that performs some lengthy operations. Eventually,
he get warnings like:

WARNING: buffer refcount leak: [779] (rel=1663/16440/52989, blockNum=3,
flags=0x27, refcount=1 2)

I traced this to the function PrintBufferLeakWarning. AFAICS, it's only
called from the function ResourceOwnerReleaseInternal under the
following comment:

* During a commit, there shouldn't be any remaining pins --- that
* would indicate failure to clean up the executor correctly --- so
* issue warnings. In the abort case, just clean up quietly.

I have no idea where to go from here. What should I look for when trying
to find the cause of such warnings?

Regards,
Thomas Hallgren

#2Martijn van Oosterhout
kleptog@svana.org
In reply to: Thomas Hallgren (#1)
Re: refcount leak warnings

On Tue, Jun 27, 2006 at 03:55:06PM +0200, Thomas Hallgren wrote:

I have a PL/Java user that performs some lengthy operations. Eventually,
he get warnings like:

WARNING: buffer refcount leak: [779] (rel=1663/16440/52989, blockNum=3,
flags=0x27, refcount=1 2)

I think the comment about failing to clean up is correct. AIUI, if
you've done a heap_open without a heap_close, or an index_open without
an index_close, you'll get warnings like this. Maybe using SPI without
clearing everything.

Obviously something didn't get cleaned up somewhere, but what? Maybe
identifying the rel and looking at that block might help identify the
issue.

Have a ncie day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Show quoted text

From each according to his ability. To each according to his ability to litigate.

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Thomas Hallgren (#1)
Re: refcount leak warnings

Thomas Hallgren <thomas@tada.se> writes:

I have a PL/Java user that performs some lengthy operations. Eventually,
he get warnings like:

WARNING: buffer refcount leak: [779] (rel=1663/16440/52989, blockNum=3,
flags=0x27, refcount=1 2)

Look for ReadBuffer calls not matched by ReleaseBuffer.

regards, tom lane