On Wed, Apr 24, 2002 at 06:13:28PM -0400, Tom Lane wrote:
>
> Is that sufficient? The clients probably are not affected by quite as
> many config options as the server, but they still have a nontrivial
> list. (Multibyte, SSL, Kerberos come to mind at once.) I'd not like
> to see us assume tha
Mario Weilguni wrote:
> Am Mittwoch, 24. April 2002 16:03 schrieb Bruce Momjian:
> > OK, I have applied the following patch to fix these warnings. However,
> > I need Mario to confirm these are the right changes. Thanks.
>
> I've checked it and works fine, but the memcpy() prototype says it sho
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> select compilation_options();
> This assumes that compilation options only matter in the server and that
> only SQL users would be interested in them. In fact, compilation options
> affect client and utility programs as well, and
Tom Lane writes:
> This could usefully be combined with the nearby thread about recording
> configuration options (started by Thomas). I'd be inclined to make it
> a low-footprint affair where you do something like
>
> select compilation_options();
>
> and you get back a long textual list
Am Mittwoch, 24. April 2002 16:03 schrieb Bruce Momjian:
> OK, I have applied the following patch to fix these warnings. However,
> I need Mario to confirm these are the right changes. Thanks.
I've checked it and works fine, but the memcpy() prototype says it should be
void pointers. Will this
Philip Warner <[EMAIL PROTECTED]> writes:
> At 16:46 15/04/02 +0200, Mario Weilguni wrote:
>> And how about getting database internals via SQL-functions - e.g. getting
>> BLCSIZE, LOBBLCSIZE?
> ISTM that there would be some merit in making a selection of compile-time
> options available via SQL
] Inefficient handling of LO-restore + Patch
OK, I have applied the following patch to fix these warnings. However,
I need Mario to confirm these are the right changes. Thanks.
---
Peter Eisentraut wrote:
> This patch d
OK, I have applied the following patch to fix these warnings. However,
I need Mario to confirm these are the right changes. Thanks.
---
Peter Eisentraut wrote:
> This patch does not compile correctly:
>
> pg_backup_archi
At 16:46 15/04/02 +0200, Mario Weilguni wrote:
>And how about getting database internals via SQL-functions - e.g. getting
>BLCSIZE, LOBBLCSIZE?
ISTM that there would be some merit in making a selection of compile-time
options available via SQL. Is this worth considering?
---
This patch does not compile correctly:
pg_backup_archiver.c: In function `ahwrite':
pg_backup_archiver.c:1252: warning: pointer of type `void *' used in arithmetic
pg_backup_archiver.c:1259: warning: pointer of type `void *' used in arithmetic
pg_backup_archiver.c:1263: warning: pointer of type `
Patch applied. Thanks.
---
Mario Weilguni wrote:
> Am Donnerstag, 11. April 2002 17:44 schrieb Tom Lane:
> > "Mario Weilguni" <[EMAIL PROTECTED]> writes:
> > > And I did not find out how I can detect the large object
> >
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Mario Weilguni wrote:
> Am Donnerstag, 11. Apr
Bruce Momjian <[EMAIL PROTECTED]> 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 afte
Tom Lane wrote:
> "Mario Weilguni" <[EMAIL PROTECTED]> 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
of LO-restore + Patch
"Mario Weilguni" <[EMAIL PROTECTED]> 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 def
"Mario Weilguni" <[EMAIL PROTECTED]> 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. Anyon
>"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_con
Am Donnerstag, 11. April 2002 17:44 schrieb Tom Lane:
> "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)
>
You did not answer if it's
"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, si
I've detected that the restoring of large objects may consume huge amounts of
diskspace when using unusual blocksizes (e.g. 32KB). My setup is Postgresql-7.2.1
+ 32KB blocks + LOBLKSIZE 16KB, a unusual combination I think, , because this setup
+gave
the very best performance. I wanted to restore
20 matches
Mail list logo
