On Mon, Jun 24, 2013 at 06:03:40PM +0000, Stuart Ford wrote:
> On 24/06/2013 17:18, "Bruce Momjian" <bruce@momjian.us> wrote:
>
>
> >On Mon, Jun 24, 2013 at 03:25:44PM +0000, Stuart Ford wrote:
> >> On 24/06/2013 14:00, "Bruce Momjian" <bruce@momjian.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?
> >
> >Yep. If it fails for some reason, just delete the contents of
> >pg_largeobject_metadata and run it again.
>
> Do you know if not running this script would explain the fact that our
> dump file sizes have been much smaller than expected?
It might be possible if lack of pg_largeobject_metadata values causes
your large objects not to be dumped; I have not tested this.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
