Re: Errors when restoring backup created by pg_dumpall
От | PopeRigby |
---|---|
Тема | Re: Errors when restoring backup created by pg_dumpall |
Дата | |
Msg-id | aa9df674-0f08-458b-8f09-08cfb57b915c@mailbox.org обсуждение исходный текст |
Ответ на | Re: Errors when restoring backup created by pg_dumpall (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: Errors when restoring backup created by pg_dumpall
|
Список | pgsql-general |
On 12/5/24 14:48, Adrian Klaver wrote: > On 12/5/24 14:32, PopeRigby wrote: >> On 12/1/24 13:55, Tom Lane wrote: >>> Adrian Klaver <adrian.klaver@aklaver.com> writes: >>>> On 12/1/24 13:14, Tom Lane wrote: >>>>> It would be useful to know what is the command at line 4102 >>>>> of all.sql. >>>> It is here: >>>> https://gist.github.com/poperigby/fcb59eb6c22c6051800e06a0ec482b49 >>>> CREATE TABLE public.geodata_places ( >>>> id integer NOT NULL, >>>> name character varying(200) NOT NULL, >>>> longitude double precision NOT NULL, >>>> latitude double precision NOT NULL, >>>> "countryCode" character(2) NOT NULL, >>>> "admin1Code" character varying(20), >>>> "admin2Code" character varying(80), >>>> "modificationDate" date NOT NULL, >>>> "earthCoord" public.earth GENERATED ALWAYS AS >>>> (public.ll_to_earth(latitude, longitude)) STORED, >>>> "admin1Name" character varying, >>>> "admin2Name" character varying, >>>> "alternateNames" character varying >>>> ); >>> Ah! Then the failure occurs because we do a planning pass on the >>> GENERATED expression (I don't remember exactly why that's needed >>> during CREATE TABLE). So maybe messing with the dump script's >>> search_path setting *would* be enough to get you past that. >>> >>> Having said that, the CREATE should have been seeing the new-style >>> definition of ll_to_earth() if the 1.2 version of earthdistance >>> was correctly installed. >>> >>> regards, tom lane >> >> So, is there anything I can do to fix this particular backup? I'm >> kind of stuck here. There's also the issue with it for some reason >> failing to connect to the lldap database after it literally just >> created it. Some weird things going on. >> > > In the pg_dumpall sql script did you change: > > SELECT pg_catalog.set_config('search_path', '', false); > > to > > SELECT pg_catalog.set_config('search_path', 'public', false); > > ? > > > Show us the connection error you got for the lldap database. > 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?
В списке pgsql-general по дате отправления: