>"Mario Weilguni" <mario.weilguni@icomedias.com> writes:
>> And I did not find out how I can detect the large object
>> chunksize, either from getting it from the headers (include
>> "storage/large_object.h" did not work)
>
>Why not?
>
>Still, it might make sense to move the LOBLKSIZE definition into
>pg_config.h, since as you say it's of some interest to clients like
>pg_dump.

I tried another approach to detect the LOBLKSIZE of the destination server:
* at restore time, create a LO large enough to be split in two parts (e.g. BLCSIZE+1)
* select octet_length(data) from pg_largeobject where loid=OIDOFOBJECT and pageno=0
* select lo_unlink(OIDOFOBJECT)

IMO this gives the advantage that the LOBLKSIZE is taken from the database I'm restoring to, and not a constant defined at compile time. Otherwise, it wastes an OID.

Is there a way to get compile-time settings (such as BLCSIZE, LOBLKSIZE and such via functions - e.g.
select pginternal('BLCSIZE') or something similar? 


I tested with and without my patch against 2 Gigabytes of LO's using MD5, and got exactly the same result on all 25000 large objects. So I think my patch is safe. If there's interest for integration into pg_dump, I'll prepare a patch for the current CVS version.



Mon, 15 Apr 2002 11:24:40 +0200
"Mario Weilguni" <mario.weilguni@icomedias.com>
Re: Inefficient handling of LO-restore + Patch 
"Mario Weilguni" <mario.weilguni@icomedias.com> writes:
> * select octet_length(data) from pg_largeobject where loid=OIDOFOBJECT and pageno=0

This really should not work if you're not superuser.  Right now it does,
but I think that's an oversight in the default permissions settings for
system tables.  Anyone object if I turn off public read access to
pg_largeobject?

			regards, tom lane

Mon, 15 Apr 2002 10:32:10 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Inefficient handling of LO-restore + Patch 
Tom Lane wrote:
> "Mario Weilguni" <mario.weilguni@icomedias.com> writes:
> > * select octet_length(data) from pg_largeobject where loid=OIDOFOBJECT and pageno=0
> 
> This really should not work if you're not superuser.  Right now it does,
> but I think that's an oversight in the default permissions settings for
> system tables.  Anyone object if I turn off public read access to
> pg_largeobject?

Please do whatever you can to tighten it up. I thought we needed to keep
read access so people could get to their large objects, but maybe not.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 15 Apr 2002 15:17:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Inefficient handling of LO-restore + Patch
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Anyone object if I turn off public read access to
>> pg_largeobject?

> Please do whatever you can to tighten it up. I thought we needed to keep
> read access so people could get to their large objects, but maybe not.

Yeah, right after sending that message I remembered that we had already
discussed this and concluded it would break clients :-(.

There's really no security for large objects anyway, since if you know
or can guess the OID of one you can read (or write!) it regardless.
Not much point in turning off read access on pg_largeobject unless we
rethink that ...

			regards, tom lane

Mon, 15 Apr 2002 15:24:20 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Inefficient handling of LO-restore + Patch 