Re: pg_largeobject implementation question - Mailing list pgsql-hackers

From Scott Corscadden
Subject Re: pg_largeobject implementation question
Date
Msg-id 78360456-98DD-4A7B-8762-41D00C3C6219@corscadden.ca
Whole thread Raw
In response to Re: pg_largeobject implementation question  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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
patchlevel though). After we do this we should be able to do a regular, normal pg_dump (not excluding anything) to get
from8.4 -> 9.2 in a few weeks from now. 

Thanks so much Tom.

./scc

On 2012-10-10, at 11:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Scott Corscadden <scott@corscadden.ca> 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 general, all built-in OID columns have mechanisms for choosing
> nonconflicting new values --- but in 9.0 and up, pg_largeobject_metadata
> is the authoritative store of "existing OIDs" for blobs, not
> pg_largeobject.
>
>             regards, tom lane




pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: No, pg_size_pretty(numeric) was not such a hot idea
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: [PATCH] Make pg_basebackup configure and start standby [Review]