On Apr 24, 2025, at 11:18, Matheus Alcantara <matheusssil...@gmail.com> wrote:
> In v2 I've moved the logic to remove the /extension to > parse_extension_control_file(), do you think that this Assert on this > function would still be wrong? IIUC we should always have /extension at > the end of "control_dir" at this place, because the > extension_control_path GUC will omit the /extension at the end and we > will force it to have the suffix on the path at > find_extension_control_filename() and > get_extension_control_directories() functions. I'm missing something > here? I took this patch for a spin and managed to make it core dump. How? Well I installed semver with this command: ```sh make prefix=/Users/david/Downloads install ``` Then set the search paths and restarted: ```ini extension_control_path = '/Users/david/Downloads/share/extension:$system' dynamic_library_path = '/Users/david/Downloads/lib:$libdir' ``` Then I connected and ran `CREATE EXTENSION semver` and it segfaulted. I poked around for a few minutes and realized that my prefix is not what I expected. Because it doesn’t contain the string “postgres”, PGXS helpfully adds it. The actual paths are: ```ini extension_control_path = '/Users/david/Downloads/share/postgresql/extension:$system' dynamic_library_path = '/Users/david/Downloads/lib/postgresql:$libdir' ``` With that fix it no longer segafulted. So I presume something crashes when a directory or file doesn’t exist. But I am not at all sure we want this prefix behavior for installing extensions. I get that has been the behavior for setting the main sharedir and libdir for Postgres, but I don’t know that it makes sense for extension prefixes. Best, David
signature.asc
Description: Message signed with OpenPGP