Message-ID: <19d5f2c7-1252-4442-accb-8aa2cb289ad0@mailbox.org>
Date: Thu, 5 Dec 2024 14:32:11 -0800
MIME-Version: 1.0
Subject: Re: Errors when restoring backup created by pg_dumpall
To: Tom Lane <tgl@sss.pgh.pa.us>, Adrian Klaver <adrian.klaver@aklaver.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
 "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
References: <6a6439f1-8039-44e2-8fb9-59028f7f2014@mailbox.org>
 <cba48d2c-0987-4233-a86f-2e693677efd3@aklaver.com>
 <9c5ba566-27b8-4e8c-bf7d-2dc561509991@mailbox.org>
 <CAKFQuwaB5GuUNuyiUbS0ah-LYXepHLPnOHrP7g8RMz8ywOm3zQ@mail.gmail.com>
 <ff94f628-27af-4c3a-9590-cba38bb5d2d1@mailbox.org>
 <CAKFQuwYQUequkYVS8SLgC1L0TOdWNK=xVyxnPD9RPPwfvYRFSQ@mail.gmail.com>
 <41791b6d-aaf5-4fed-9cc3-e89bc49e8637@mailbox.org>
 <CAKFQuwbe4TSU_LxsrGxgcv4DfQq2x-UNoyKx-ABy36PhvbGCdg@mail.gmail.com>
 <1257068.1733025493@sss.pgh.pa.us>
 <06425038-e012-4bac-aec1-d9541436f893@mailbox.org>
 <92405f98-7f0c-4442-8252-697352daefc1@aklaver.com>
 <1470486.1733087658@sss.pgh.pa.us>
 <4ab662d8-57cc-471f-8a58-cfd71d1cea22@aklaver.com>
 <1475512.1733090108@sss.pgh.pa.us>
Content-Language: en-US
From: PopeRigby <poperigby@mailbox.org>
In-Reply-To: <1475512.1733090108@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/19d5f2c7-1252-4442-accb-8aa2cb289ad0%40mailbox.org>
Precedence: bulk

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.