Re: pg_largeobject.sql script not run after upgrade

From: Stuart Ford <stuart(dot)ford(at)glide(dot)uk(dot)com>
To: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_largeobject.sql script not run after upgrade
Date: 2013-06-24 15:25:44
Message-ID: CDEE234B.7395%stuart.ford@glide.uk.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 24/06/2013 14:00, "Bruce Momjian" <bruce(at)momjian(dot)us> wrote:

>
>Looking further, here is the command that is executed:
>
> SELECT pg_catalog.lo_create(t.loid)
> FROM (SELECT DISTINCT loid FROM pg_catalog.pg_largeobject) AS t;
>
>If you have created _new_ large objects since the upgrde, the script
>might throw an error, as there is already metadata for those large
>objects. You might need to delete the rows in pg_largeobject_metadata
>before running the script; this will reset all the large object
>permissions to default.

There doesn't appear to be, if this command, which returns 0, is correct:

select count(*) from pg_catalog.pg_largeobject_metadata ;

So it's OK to go ahead and run at any time?

Stuart

This email and any attachments contain confidential and proprietary information of Glide Utilities Limited intended only for the use of the person to whom it is addressed. Unauthorised disclosure, copying or distribution of the email or its content may result in legal liability. If you have received the email in error, please immediately notify us by telephone on +44 333 666 5555 or email glide(at)glide(dot)uk(dot)com

The sender does not accept liability for any loss or damage from receipt or use thereof which arises as a result of internet transmission. Any views/opinions expressed within this email and any attachments are that of the individual and not necessarily that of Glide Utilities Limited.

Glide is a registered trademark of Glide Utilities Limited. Registered Office: Alpha Tower, Suffolk Street Queensway, Birmingham, B1 1TT. Registered in England & Wales. Registered Company No. 06194523.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message boraldomaster 2013-06-24 15:26:58 Re: Index scan and bitmap index scan - hard to understand how planner chooses
Previous Message Jeff Janes 2013-06-24 15:15:16 Re: Re: Index scan and bitmap index scan - hard to understand how planner chooses