public inbox for [email protected]
help / color / mirror / Atom feedFrom: PopeRigby <[email protected]>
To: Adrian Klaver <[email protected]>
To: Tom Lane <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Errors when restoring backup created by pg_dumpall
Date: Sat, 7 Dec 2024 11:25:29 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CAKFQuwaB5GuUNuyiUbS0ah-LYXepHLPnOHrP7g8RMz8ywOm3zQ@mail.gmail.com>
<[email protected]>
<CAKFQuwYQUequkYVS8SLgC1L0TOdWNK=xVyxnPD9RPPwfvYRFSQ@mail.gmail.com>
<[email protected]>
<CAKFQuwbe4TSU_LxsrGxgcv4DfQq2x-UNoyKx-ABy36PhvbGCdg@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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 <[email protected]> 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?
view thread (20+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Errors when restoring backup created by pg_dumpall
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox