Hi
pg_largeobject is creating performance issues as it grow due to single
point storage(for all tables)
is there any alternate apart from bytea ?
like configuration large-object-table at table-column level and oid
PK(primary key) stored at pg_largeobject
Thanks
Sridhar
A very timely answer, and we'd debating moving to 9.2 at the same time but
decided on staying on the 8.4 line (latest patch level though). After we do
this we should be able to do a regular, normal pg_dump (not excluding anything)
to get from 8.4 -> 9.2 in a few weeks from now.
Thanks so much T
Scott Corscadden writes:
> ** MY QUESTION ** - Will pg_largeobject automatically choose new OIDs that
> don't conflict, if I've added lo's this way, by direct COPY?
In 8.4, yes. In later versions, you'd need to do something about
creating corresponding rows in pg_largeobject_metadata.
In gener
I'm pruning an 8.4 database that was using a *lot* of space in pg_largeobject
(400GB according to my size query). What I've done seems to work, but I don't
know if there's a time-bomb waiting for me, so I have to ask you who've
implemented this part. Steps:
1) On new.better.server.com:
I have added to TODO:
* Allow moving system tables to other tablespaces, where
possible
---
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > With our new tablespace set up, is it
On Wed, 23 Jun 2004, Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > With our new tablespace set up, is it ever possible for someone to move
> > pg_largeobject to another tablespace?
>
> Assuming that ALTER TABLE SET TABLESPACE gets in, my preferred answer is
> to apply t
If nothing else comes to mind, a reasonable compromise for 7.5 would be
to forbid moving any system catalog except pg_largeobject and its
indexes ...
Plus pg_dump support for it :/
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe comman
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> With our new tablespace set up, is it ever possible for someone to move
> pg_largeobject to another tablespace?
Assuming that ALTER TABLE SET TABLESPACE gets in, my preferred answer is
to apply that operation to pg_largeobject.
We do need to
With our new tablespace set up, is it ever possible for someone to move
pg_largeobject to another tablespace?
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
At 19:49 27/06/01 -0400, Tom Lane wrote:
>
>Hmm. [sound of grepping] So does psql's \lo_list command. That's
>annoying ... the list of large object OIDs is *exactly* what you'd want
>to hide from the unwashed masses. Oh well, I'll leave bad enough alone
>for now.
>
I suspect this would be cle
Philip Warner <[EMAIL PROTECTED]> writes:
> At 12:27 27/06/01 -0400, Tom Lane wrote:
>> I propose that initdb should do
>> REVOKE ALL on pg_largeobject FROM public
> May have an issue with PG_DUMP, which does a 'select oid from
> pg_largeobject', I think.
Hmm. [sound of grepping] So does psql'
At 12:27 27/06/01 -0400, Tom Lane wrote:
>I propose that initdb should do
> REVOKE ALL on pg_largeobject FROM public
>
May have an issue with PG_DUMP, which does a 'select oid from
pg_largeobject', I think.
Philip Warner
I propose that initdb should do
REVOKE ALL on pg_largeobject FROM public
same as it does already for pg_shadow and pg_statistic. This would
prevent non-superusers from examining or modifying large objects
except through the LO operations.
This is only security through obscurity, of cours
13 matches
Mail list logo
