>"Mario Weilguni" <[EMAIL PROTECTED]> 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.
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
