Search Postgresql Archives

Re: Errors when restoring backup created by pg_dumpall

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 9, 2024 at 3:14 PM PopeRigby <poperigby@xxxxxxxxxxx> wrote:
On 12/7/24 11:58, David G. Johnston wrote:
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby <poperigby@xxxxxxxxxxx> wrote:

It actually looks like setting those all to have public fixed all the
errors, including the one with lldap. So, how can I get it to not put
public there automatically for next time?


I assume you mean "get it to put public there" (i.e., the "not" is a typo)

You cannot.  The security team has decided to not permit an opt-in bypass of the lock-downs implemented to fix CVE-2018-1058.

Your only real choice at the moment is to replace the function call in the generated _expression_ with a custom function and in that custom function's create function command attach a "set search_path to public" clause.  That will prevent inlining and also ensure the public schema is in the search_path when executing the public.ll_to_earth function call.  With that in place the empty search_path in the dump file will no longer matter.

Yeah, that was a typo. It seems weird that this behavior would be broken by default though, is there anything that could fix it upstream?


You saw and tried the work being done "upstream" to fix the situation.  It's a big knot in the system and it isn't easy (or highly motivated) to untangle unfortunately...

David J.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux