Hi.

Due to some bug report for the postgresql python interface, I started
testing the current large objects support. Two points seems to be wrong,
but yet I only studied one.

LO may span over some blocks and whenever a block boundary is crossed (for
the first access for example, or whenever a full block has been read), the
lo_read() query gets a: 
   "NOTICE:  buffer leak [xx] detected in BufferPoolCheckLeak()"
The leak is located in an index_getnext() call to seek the next
block (using a btree index). But as this part of code is less easy to
follow and I can't go further.
This call is locate in inv_fetchtup(), called by inv_read() from the
inv_api.c file.

Could someone give me some pointers on how I could track where the faulty
buffer is allocated?
 
Thanks.

---
Pascal ANDRE, Internet and Media Consulting
andre(at)via(dot)ecp(dot)fr
"Use the source, Luke. Be one with the Code."  -- Linus Torvalds

In response to

• NEW POSTGRESQL LOGOS at 1998-06-03 08:35:10 from Steve Logue

pgsql-hackers by date

Next:	From: Hal Snyder	Date: 1998-06-03 14:20:30
	Subject: Re: [HACKERS] keeping track of connections
Previous:	From: Bruce Momjian	Date: 1998-06-03 13:00:11
	Subject: Re: [HACKERS] dump/reload

pgsql-general by date

Next:	From: Marin D	Date: 1998-06-03 15:53:26
	Subject: European/American dates
Previous:	From: The Hermit Hacker	Date: 1998-06-03 13:45:01
	Subject: PostgreSQL User Gallery ...