Re: pg_largeobject implementation question

From: Scott Corscadden <scott(at)corscadden(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "support(at)binnj(dot)com" <support(at)binnj(dot)com>
Subject: Re: pg_largeobject implementation question
Date: 2012-10-10 19:13:35
Message-ID: 78360456-98DD-4A7B-8762-41D00C3C6219@corscadden.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 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 Tom.

./scc

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

> Scott Corscadden <scott(at)corscadden(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Boszormenyi Zoltan 2012-10-10 19:58:08 Re: [PATCH] Make pg_basebackup configure and start standby [Review]
Previous Message Josh Berkus 2012-10-10 18:49:50 Re: No, pg_size_pretty(numeric) was not such a hot idea