From: | andre(at)via(dot)ecp(dot)fr |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Buffer leak? |
Date: | 1998-06-03 14:15:31 |
Message-ID: | Pine.LNX.3.96.980603160120.9579A-100000@Chimay |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Marin D | 1998-06-03 15:53:26 | European/American dates |
Previous Message | The Hermit Hacker | 1998-06-03 13:45:01 | PostgreSQL User Gallery ... |
From | Date | Subject | |
---|---|---|---|
Next Message | Hal Snyder | 1998-06-03 14:20:30 | Re: [HACKERS] keeping track of connections |
Previous Message | Bruce Momjian | 1998-06-03 13:00:11 | Re: [HACKERS] dump/reload |