public inbox for [email protected]help / color / mirror / Atom feed
Re: Errors when restoring backup created by pg_dumpall 20+ messages / 4 participants [nested] [flat]
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-01 21:14 Tom Lane <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Tom Lane @ 2024-12-01 21:14 UTC (permalink / raw) To: Adrian Klaver <[email protected]>; +Cc: PopeRigby <[email protected]>; David G. Johnston <[email protected]>; pgsql-general Adrian Klaver <[email protected]> writes: > On 12/1/24 12:05, PopeRigby wrote: >> I'm still getting this error: >> >> psql:all.sql:4102: ERROR: type "earth" does not exist >> LINE 1: ...ians($1))*sin(radians($2))),earth()*sin(radians($1)))::earth > The issue is still this: > SELECT pg_catalog.set_config('search_path', '', false); > in the pg_dumpall output. We've done that for some time, though. > As was suggested before change the above to: > SELECT pg_catalog.set_config('search_path', 'public', false); > in the pg_dumpall output file. I'm betting that won't help. The new-in-17 behavior is that maintenance commands such as CREATE INDEX internally force a "safe" search_path, regardless of the prevailing setting. It would be useful to know what is the command at line 4102 of all.sql. regards, tom lane ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-01 21:36 Adrian Klaver <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Adrian Klaver @ 2024-12-01 21:36 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: PopeRigby <[email protected]>; David G. Johnston <[email protected]>; pgsql-general On 12/1/24 13:14, Tom Lane wrote: > Adrian Klaver <[email protected]> writes: >> On 12/1/24 12:05, PopeRigby wrote: >>> I'm still getting this error: >>> >>> psql:all.sql:4102: ERROR: type "earth" does not exist >>> LINE 1: ...ians($1))*sin(radians($2))),earth()*sin(radians($1)))::earth > >> The issue is still this: >> SELECT pg_catalog.set_config('search_path', '', false); >> in the pg_dumpall output. > > We've done that for some time, though. > >> As was suggested before change the above to: >> SELECT pg_catalog.set_config('search_path', 'public', false); >> in the pg_dumpall output file. > > I'm betting that won't help. The new-in-17 behavior is that > maintenance commands such as CREATE INDEX internally force > a "safe" search_path, regardless of the prevailing setting. > > 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 ); > > regards, tom lane -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-01 21:55 Tom Lane <[email protected]> parent: Adrian Klaver <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Tom Lane @ 2024-12-01 21:55 UTC (permalink / raw) To: Adrian Klaver <[email protected]>; +Cc: PopeRigby <[email protected]>; David G. Johnston <[email protected]>; pgsql-general 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 ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-05 22:32 PopeRigby <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: PopeRigby @ 2024-12-05 22:32 UTC (permalink / raw) To: Tom Lane <[email protected]>; Adrian Klaver <[email protected]>; +Cc: David G. Johnston <[email protected]>; pgsql-general 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. ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-05 22:48 Adrian Klaver <[email protected]> parent: PopeRigby <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Adrian Klaver @ 2024-12-05 22:48 UTC (permalink / raw) To: PopeRigby <[email protected]>; Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; pgsql-general 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. -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-07 19:25 PopeRigby <[email protected]> parent: Adrian Klaver <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: PopeRigby @ 2024-12-07 19:25 UTC (permalink / raw) To: Adrian Klaver <[email protected]>; Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; 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 <[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? ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-07 19:58 David G. Johnston <[email protected]> parent: PopeRigby <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: David G. Johnston @ 2024-12-07 19:58 UTC (permalink / raw) To: PopeRigby <[email protected]>; +Cc: Adrian Klaver <[email protected]>; Tom Lane <[email protected]>; pgsql-general On Sat, Dec 7, 2024 at 12:25 PM PopeRigby <[email protected]> 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. David J. ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-09 22:14 PopeRigby <[email protected]> parent: David G. Johnston <[email protected]> 0 siblings, 3 replies; 20+ messages in thread From: PopeRigby @ 2024-12-09 22:14 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: Adrian Klaver <[email protected]>; Tom Lane <[email protected]>; pgsql-general On 12/7/24 11:58, David G. Johnston wrote: > On Sat, Dec 7, 2024 at 12:25 PM PopeRigby <[email protected]> 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. > > David J. > 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? ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-09 22:31 David G. Johnston <[email protected]> parent: PopeRigby <[email protected]> 2 siblings, 1 reply; 20+ messages in thread From: David G. Johnston @ 2024-12-09 22:31 UTC (permalink / raw) To: PopeRigby <[email protected]>; +Cc: Adrian Klaver <[email protected]>; Tom Lane <[email protected]>; pgsql-general On Mon, Dec 9, 2024 at 3:14 PM PopeRigby <[email protected]> wrote: > On 12/7/24 11:58, David G. Johnston wrote: > > On Sat, Dec 7, 2024 at 12:25 PM PopeRigby <[email protected]> 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. ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-09 22:34 PopeRigby <[email protected]> parent: David G. Johnston <[email protected]> 0 siblings, 0 replies; 20+ messages in thread From: PopeRigby @ 2024-12-09 22:34 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: Adrian Klaver <[email protected]>; Tom Lane <[email protected]>; pgsql-general On 12/9/24 14:31, David G. Johnston wrote: > On Mon, Dec 9, 2024 at 3:14 PM PopeRigby <[email protected]> wrote: > > On 12/7/24 11:58, David G. Johnston wrote: >> On Sat, Dec 7, 2024 at 12:25 PM PopeRigby <[email protected]> >> 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. > Understood. Well, at least it was a fairly easy fix. Thanks for the help :) ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-09 22:47 Adrian Klaver <[email protected]> parent: PopeRigby <[email protected]> 2 siblings, 1 reply; 20+ messages in thread From: Adrian Klaver @ 2024-12-09 22:47 UTC (permalink / raw) To: PopeRigby <[email protected]>; David G. Johnston <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-general On 12/9/24 14:14, PopeRigby wrote: > On 12/7/24 11:58, David G. Johnston wrote: >> On Sat, Dec 7, 2024 at 12:25 PM PopeRigby <[email protected]> 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. >> >> David J. >> > 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 could file an issue here: https://www.postgresql.org/account/login/?next=/account/submitbug/ Ask if the developers could use the mechanisms available here: https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION to schema qualify the objects in the extension. Not sure if that will fly or not, but it is worth a shot. -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-09 22:49 PopeRigby <[email protected]> parent: Adrian Klaver <[email protected]> 0 siblings, 0 replies; 20+ messages in thread From: PopeRigby @ 2024-12-09 22:49 UTC (permalink / raw) To: Adrian Klaver <[email protected]>; David G. Johnston <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-general On 12/9/24 14:47, Adrian Klaver wrote: > On 12/9/24 14:14, PopeRigby wrote: >> On 12/7/24 11:58, David G. Johnston wrote: >>> On Sat, Dec 7, 2024 at 12:25 PM PopeRigby <[email protected]> >>> 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. >>> >>> David J. >>> >> 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 could file an issue here: > > https://www.postgresql.org/account/login/?next=/account/submitbug/ > > Ask if the developers could use the mechanisms available here: > > https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION > > > to schema qualify the objects in the extension. > > Not sure if that will fly or not, but it is worth a shot. > Will do! ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-09 23:23 Tom Lane <[email protected]> parent: PopeRigby <[email protected]> 2 siblings, 2 replies; 20+ messages in thread From: Tom Lane @ 2024-12-09 23:23 UTC (permalink / raw) To: Adrian Klaver <[email protected]>; +Cc: PopeRigby <[email protected]>; David G. Johnston <[email protected]>; pgsql-general Adrian Klaver <[email protected]> writes: > You could file an issue here: > https://www.postgresql.org/account/login/?next=/account/submitbug/ > Ask if the developers could use the mechanisms available here: > https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION This wouldn't really move the needle, since (a) there is not some magic group of people that will become involved who aren't already and (b) the requested fix seems exactly the same as the work already in progress at [1]. What would help is to figure out why the proposed patch didn't seem to work for you. I continue to suspect that you didn't really install the updated extension, but it's unclear. regards, tom lane [1] https://www.postgresql.org/message-id/flat/[email protected] ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-09 23:30 PopeRigby <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 1 reply; 20+ messages in thread From: PopeRigby @ 2024-12-09 23:30 UTC (permalink / raw) To: Tom Lane <[email protected]>; Adrian Klaver <[email protected]>; +Cc: David G. Johnston <[email protected]>; pgsql-general On 12/9/24 15:23, Tom Lane wrote: > Adrian Klaver <[email protected]> writes: >> You could file an issue here: >> https://www.postgresql.org/account/login/?next=/account/submitbug/ >> Ask if the developers could use the mechanisms available here: >> https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION > This wouldn't really move the needle, since (a) there is not some > magic group of people that will become involved who aren't already > and (b) the requested fix seems exactly the same as the work > already in progress at [1]. > > What would help is to figure out why the proposed patch didn't > seem to work for you. I continue to suspect that you didn't > really install the updated extension, but it's unclear. > > regards, tom lane > > [1] https://www.postgresql.org/message-id/flat/[email protected] I compiled and installed PostgreSQL with the patch, and restarted it, so unless there are other steps I'm not sure what I could have done wrong. ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-10 00:07 Adrian Klaver <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 0 replies; 20+ messages in thread From: Adrian Klaver @ 2024-12-10 00:07 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: PopeRigby <[email protected]>; David G. Johnston <[email protected]>; pgsql-general On 12/9/24 15:23, Tom Lane wrote: > Adrian Klaver <[email protected]> writes: >> You could file an issue here: >> https://www.postgresql.org/account/login/?next=/account/submitbug/ >> Ask if the developers could use the mechanisms available here: >> https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION > > This wouldn't really move the needle, since (a) there is not some > magic group of people that will become involved who aren't already > and (b) the requested fix seems exactly the same as the work > already in progress at [1]. I made the suggestion to the OP, my mistake. Somewhere I missed that work was being done on this. > > What would help is to figure out why the proposed patch didn't > seem to work for you. I continue to suspect that you didn't > really install the updated extension, but it's unclea Are you referring to this?: https://www.postgresql.org/message-id/3316564.aeNJFYEL58@aivenlaptop > > regards, tom lane > > [1] https://www.postgresql.org/message-id/flat/[email protected] -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-10 00:31 Adrian Klaver <[email protected]> parent: PopeRigby <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Adrian Klaver @ 2024-12-10 00:31 UTC (permalink / raw) To: PopeRigby <[email protected]>; Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; pgsql-general On 12/9/24 15:30, PopeRigby wrote: > On 12/9/24 15:23, Tom Lane wrote: >> Adrian Klaver <[email protected]> writes: >>> You could file an issue here: >>> https://www.postgresql.org/account/login/?next=/account/submitbug/ >>> Ask if the developers could use the mechanisms available here: >>> https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION >> This wouldn't really move the needle, since (a) there is not some >> magic group of people that will become involved who aren't already >> and (b) the requested fix seems exactly the same as the work >> already in progress at [1]. >> >> What would help is to figure out why the proposed patch didn't >> seem to work for you. I continue to suspect that you didn't >> really install the updated extension, but it's unclear. >> >> regards, tom lane >> >> [1] >> https://www.postgresql.org/message-id/flat/[email protected] > > I compiled and installed PostgreSQL with the patch, and restarted it, so > unless there are other steps I'm not sure what I could have done wrong. > What was the source of the patch? -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-11 03:05 PopeRigby <[email protected]> parent: Adrian Klaver <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: PopeRigby @ 2024-12-11 03:05 UTC (permalink / raw) To: Adrian Klaver <[email protected]>; Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; pgsql-general On 12/9/24 16:31, Adrian Klaver wrote: > On 12/9/24 15:30, PopeRigby wrote: >> On 12/9/24 15:23, Tom Lane wrote: >>> Adrian Klaver <[email protected]> writes: >>>> You could file an issue here: >>>> https://www.postgresql.org/account/login/?next=/account/submitbug/ >>>> Ask if the developers could use the mechanisms available here: >>>> https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION >>>> >>> This wouldn't really move the needle, since (a) there is not some >>> magic group of people that will become involved who aren't already >>> and (b) the requested fix seems exactly the same as the work >>> already in progress at [1]. >>> >>> What would help is to figure out why the proposed patch didn't >>> seem to work for you. I continue to suspect that you didn't >>> really install the updated extension, but it's unclear. >>> >>> regards, tom lane >>> >>> [1] >>> https://www.postgresql.org/message-id/flat/[email protected] >> >> I compiled and installed PostgreSQL with the patch, and restarted it, >> so unless there are other steps I'm not sure what I could have done >> wrong. >> > > > What was the source of the patch? > This: https://www.postgresql.org/message-id/attachment/122092/0002-earthdistance-sql-functions.patch ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-11 05:22 Adrian Klaver <[email protected]> parent: PopeRigby <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Adrian Klaver @ 2024-12-11 05:22 UTC (permalink / raw) To: PopeRigby <[email protected]>; Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; pgsql-general On 12/10/24 19:05, PopeRigby wrote: > On 12/9/24 16:31, Adrian Klaver wrote: >> On 12/9/24 15:30, PopeRigby wrote: >>> On 12/9/24 15:23, Tom Lane wrote: >>>> Adrian Klaver <[email protected]> writes: >>>>> You could file an issue here: >>>>> https://www.postgresql.org/account/login/?next=/account/submitbug/ >>>>> Ask if the developers could use the mechanisms available here: >>>>> https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION >>>> This wouldn't really move the needle, since (a) there is not some >>>> magic group of people that will become involved who aren't already >>>> and (b) the requested fix seems exactly the same as the work >>>> already in progress at [1]. >>>> >>>> What would help is to figure out why the proposed patch didn't >>>> seem to work for you. I continue to suspect that you didn't >>>> really install the updated extension, but it's unclear. >>>> >>>> regards, tom lane >>>> >>>> [1] >>>> https://www.postgresql.org/message-id/flat/[email protected] >>> >>> I compiled and installed PostgreSQL with the patch, and restarted it, >>> so unless there are other steps I'm not sure what I could have done >>> wrong. >>> >> >> >> What was the source of the patch? >> > This: > https://www.postgresql.org/message-id/attachment/122092/0002-earthdistance-sql-functions.patch > If I am following correctly I believe you need this one: https://www.postgresql.org/message-id/attachment/166859/v2-0002-Use-new-style-SQL-function-in-earthd... It has the changes that include the schema qualifications. The one you used does not have those modifications. -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-13 06:19 PopeRigby <[email protected]> parent: Adrian Klaver <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: PopeRigby @ 2024-12-13 06:19 UTC (permalink / raw) To: Adrian Klaver <[email protected]>; Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; pgsql-general On 12/10/24 21:22, Adrian Klaver wrote: > On 12/10/24 19:05, PopeRigby wrote: >> On 12/9/24 16:31, Adrian Klaver wrote: >>> On 12/9/24 15:30, PopeRigby wrote: >>>> On 12/9/24 15:23, Tom Lane wrote: >>>>> Adrian Klaver <[email protected]> writes: >>>>>> You could file an issue here: >>>>>> https://www.postgresql.org/account/login/?next=/account/submitbug/ >>>>>> Ask if the developers could use the mechanisms available here: >>>>>> https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION >>>>>> >>>>> This wouldn't really move the needle, since (a) there is not some >>>>> magic group of people that will become involved who aren't already >>>>> and (b) the requested fix seems exactly the same as the work >>>>> already in progress at [1]. >>>>> >>>>> What would help is to figure out why the proposed patch didn't >>>>> seem to work for you. I continue to suspect that you didn't >>>>> really install the updated extension, but it's unclear. >>>>> >>>>> regards, tom lane >>>>> >>>>> [1] >>>>> https://www.postgresql.org/message-id/flat/[email protected] >>>> >>>> I compiled and installed PostgreSQL with the patch, and restarted >>>> it, so unless there are other steps I'm not sure what I could have >>>> done wrong. >>>> >>> >>> >>> What was the source of the patch? >>> >> This: >> https://www.postgresql.org/message-id/attachment/122092/0002-earthdistance-sql-functions.patch >> > > If I am following correctly I believe you need this one: > > https://www.postgresql.org/message-id/attachment/166859/v2-0002-Use-new-style-SQL-function-in-earthd... > > > It has the changes that include the schema qualifications. The one you > used does not have those modifications. > Beautiful. How can I follow this so I know when it gets upstream? ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Errors when restoring backup created by pg_dumpall @ 2024-12-13 16:46 Adrian Klaver <[email protected]> parent: PopeRigby <[email protected]> 0 siblings, 0 replies; 20+ messages in thread From: Adrian Klaver @ 2024-12-13 16:46 UTC (permalink / raw) To: PopeRigby <[email protected]>; Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; pgsql-general On 12/12/24 22:19, PopeRigby wrote: > On 12/10/24 21:22, Adrian Klaver wrote: >> On 12/10/24 19:05, PopeRigby wrote: >> >> If I am following correctly I believe you need this one: >> >> https://www.postgresql.org/message-id/attachment/166859/v2-0002-Use-new-style-SQL-function-in-earthd... >> >> It has the changes that include the schema qualifications. The one you >> used does not have those modifications. >> > Beautiful. How can I follow this so I know when it gets upstream? > You can check here: https://git.postgresql.org/gitweb/?p=postgresql.git;a=tree;f=contrib/earthdistance;h=282f5a80b204a48... and see when the earthdistance--1.1--1.2.sql and earthdistance--1.2.sql scripts show up. Though a formal release won't happen until the dates listed here: https://www.postgresql.org/developer/roadmap/ with nearest one being February 13th, 2025. FYI, these are target dates and not set in stone. -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 20+ messages in thread
end of thread, other threads:[~2024-12-13 16:46 UTC | newest] Thread overview: 20+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-12-01 21:14 Re: Errors when restoring backup created by pg_dumpall Tom Lane <[email protected]> 2024-12-01 21:36 ` Adrian Klaver <[email protected]> 2024-12-01 21:55 ` Tom Lane <[email protected]> 2024-12-05 22:32 ` PopeRigby <[email protected]> 2024-12-05 22:48 ` Adrian Klaver <[email protected]> 2024-12-07 19:25 ` PopeRigby <[email protected]> 2024-12-07 19:58 ` David G. Johnston <[email protected]> 2024-12-09 22:14 ` PopeRigby <[email protected]> 2024-12-09 22:31 ` David G. Johnston <[email protected]> 2024-12-09 22:34 ` PopeRigby <[email protected]> 2024-12-09 22:47 ` Adrian Klaver <[email protected]> 2024-12-09 22:49 ` PopeRigby <[email protected]> 2024-12-09 23:23 ` Tom Lane <[email protected]> 2024-12-09 23:30 ` PopeRigby <[email protected]> 2024-12-10 00:31 ` Adrian Klaver <[email protected]> 2024-12-11 03:05 ` PopeRigby <[email protected]> 2024-12-11 05:22 ` Adrian Klaver <[email protected]> 2024-12-13 06:19 ` PopeRigby <[email protected]> 2024-12-13 16:46 ` Adrian Klaver <[email protected]> 2024-12-10 00:07 ` Adrian Klaver <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox