Re: Re: Large Objects - Mailing list pgsql-general
| From | David McWherter |
|---|---|
| Subject | Re: Re: Large Objects |
| Date | |
| Msg-id | 14795.27353.638551.140778@tangent.mcs.drexel.edu Whole thread Raw |
| In response to | Re: Re: Large Objects (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: Re: Large Objects
|
| List | pgsql-general |
> currently PG stores each BLOB as an independent table --- and just to
> add insult to injury, creates an index for it :-(. So you actually have
> *two* added files in the DB directory per BLOB. Needless to say, this
> does not scale real well to large numbers of BLOBs.
>
> Denis Perchine has done the legwork to store BLOBs in a more reasonable
> fashion, ie all together in one big (but indexed!) table. His patch
> needs review by a core person before we'll consider it safe to commit,
> but I have that as a personal "must do for 7.1". So those MySQL results
> should also apply to Postgres in 7.1 and later.
I was experimenting with the patches in question, after applying
them to postgres-7.0.2. I'm encountering a nasty problem when
inserting my own huge (several megabyte) files into the relation,
that I can't quite figure out.
Apparently, what's going on is that the inserts/updates into the
pg_largeobject table result in buffers getting leaked (as
reported by BufferPoolCheckLeak()). Eventually, importing
a file results in exhausting the block free list. I think
there were a couple of places where a ReleaseBuffer was
needed, but not called...i've modified his code for inv_write_existing
to look more like:
------------
buffer = InvalidBuffer;
while ( index_getnext(...) ) {
if ( buffer != InvalidBuffer ) {
ReleaseBuffer( buffer );
buffer = InvalidBuffer;
}
heap_fetch( ..., &buffer );
index_endscan(...);
{
/* build a block of data */
...
ntup = heap_modifytuple( ... );
heap_update( ... );
heap_freetuple( ntup );
}
if ( buffer != InvalidBuffer ) {
WriteBuffer( buffer );
}
------------
The Leak-check seems to indicate that the pages that are getting
leaked are all dirty pages, which seems slightly odd to me...if
I call it at the end of this loop function (which gets called over
and over again during an import), I end up getting something that
looks like this:
-------
lockNum=56, flags=0x85, refcount=1 1)
NOTICE: Buffer Leak: [058] (freeNext=-3, freePrev=-3, relname=pg_largeobject, blockNum=9, flags=0x85, refcount=1 1)
NOTICE: Buffer Leak: [059] (freeNext=-3, freePrev=-3, relname=pg_largeobject, blockNum=58, flags=0x85, refcount=1 3)
lockNum=49, flags=0x85, refcount=1 1)
NOTICE: Buffer Leak: [061] (freeNext=-3, freePrev=-3, relname=pg_largeobject, blockNum=51, flags=0x85, refcount=1 3)
NOTICE: Buffer Leak: [062] (freeNext=-3, freePrev=-3, relname=pg_largeobject, blockNum=37, flags=0x85, refcount=1 3)
ERROR: out of free buffers: time to abort !
-----
The number of buffers leaked monotonically increases as the
import proceeds...I can't quite pin down at what location the
Buffers in question are being pinned down...
-David
----------------------[=========]------------------------
David T. McWherter udmcwher@mcs.drexel.edu
Many Myths are based on truth
-- Spock, "The Way to Eden", stardate 5832.3
pgsql-general by date: