Message-ID: <aa9df674-0f08-458b-8f09-08cfb57b915c@mailbox.org>
Date: Sat, 7 Dec 2024 11:25:29 -0800
MIME-Version: 1.0
Subject: Re: Errors when restoring backup created by pg_dumpall
To: Adrian Klaver <adrian.klaver@aklaver.com>, Tom Lane <tgl@sss.pgh.pa.us>
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>
 <19d5f2c7-1252-4442-accb-8aa2cb289ad0@mailbox.org>
 <f84a6583-50cc-416b-9abd-2b5795aa74ac@aklaver.com>
Content-Language: en-US
From: PopeRigby <poperigby@mailbox.org>
In-Reply-To: <f84a6583-50cc-416b-9abd-2b5795aa74ac@aklaver.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/aa9df674-0f08-458b-8f09-08cfb57b915c%40mailbox.org>
Precedence: bulk

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?