On 2/1/21 9:13 AM, Andrus wrote:
> Hi!
>
> >Well the user that runs the pg_dump needs to have permissions on the
> large objects. For more information see below.
>
> How to add permissions to non-superusers for this.?
>
> GRANT command
>
> GRANT { { SELECT | UPDATE } [, ...] | ALL [ PRIVILEGES ] }
> ON LARGE OBJECT/|loid|/ [, ...]
> TO/|role_specification|/ [, ...] [ WITH GRANT OPTION ]
>
> Requires large object id. How to grant backup privilege if there are no
> large objects in database ?
Your query below says there are and also returns the oid for them.
>
> Should *lo_compat_privileges
> *
>
> set in postgresql.conf or is there better way ?
Changing lo_compat_privileges is an option but it is just moving the
problem down the road. The actual fix is to find out what the large
objects are there for, who owns them, are they still necessary?. Then
based on the answers make the changes needed to future proof further
interaction with them.
>
>>> -n public -n firma74
>>>
>>> command line options are used.
>>>
>>>>
>>>> You can query that to see what is there. I would not go about
>>>> deleting until you find what the large objects are for.
>>>>
>>> select * from pg_largeobject
>>>
>>> returns empty table.
>>
> select * from pg_largeobject_metadata
>
> returns 3 rows:
>
> Oid Lomowner
>
> 200936761 30152
>
> 200936762 30152
>
> 200936767 30152
>
> How to find table and schema which is referenced by this ?
Large objects exist independent of those. The important part of the
above is lomowner. Use that oid to find the role that owns the objects here:
https://www.postgresql.org/docs/12/view-pg-roles.html
select rolname from pg_roles where oid = <lomowner>;
>
> Andrus.
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com