Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n2GY5-0001rA-BL for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Dec 2021 17:46:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n2GY4-0005mk-5P for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Dec 2021 17:46:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n2GY3-0005mb-Jl for pgsql-hackers@lists.postgresql.org; Tue, 28 Dec 2021 17:46:07 +0000 Received: from mail-io1-xd2b.google.com ([2607:f8b0:4864:20::d2b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1n2GXw-0005hP-SW for pgsql-hackers@lists.postgresql.org; Tue, 28 Dec 2021 17:46:07 +0000 Received: by mail-io1-xd2b.google.com with SMTP id u8so23421865iol.5 for ; Tue, 28 Dec 2021 09:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=NPzyK3c06VZOBShRP5a+kh8RPEWeiheLx45/fg0WisM=; b=G07JRSCTMWOXQueU/Sv2iV1N8VlF51b5ZKKnefVEe+FTpY7Cl82/8yaDQ2i0Q0QUZG y5LIpSTQOX6kBhEHLYz4JFtS6r+PvpwTOtRub4MmMpcUvSQfPvEZyzSAUAiDhPVDczAt CZoQMNa4zEbqsXlW5i62VIxE2dQkWcsoTghLtY0sYZuYIZNTWHstso35CaF7fC19sn9P c3zVSnWJXg9X80SDn8yQKs9tyIl1rqf5RJeieg6GJ0R6k3YoCpSSVal/ErR6ivsWJ301 I0ynAez83sEImxAX+ktYkjj2F/BHMNUI073WRABAaY3nSxI1/Iq+/RyNrFQxb35NhknV QcVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=NPzyK3c06VZOBShRP5a+kh8RPEWeiheLx45/fg0WisM=; b=4oS3lV/fpohQkWV34sFEuEd46YcYv8LKpDenfLhAIGtjaQXswFj+sRXqrSjcpcej9W otMmCkg0EL5fHkGMxntXOjk1YF5Vx2KtnAL3lTCpbivSjPhcFpYoHvnTKGsVdglSzvO8 z8XNLfW85UDXxbaY19LnFfgPL0PTDi+KJgfeBzShYT+bFbop2Luvf3ELzDamep1mLNMY 3fIN2DCu/bwuQIpBd7VrbD/7p1SppYzAJRGZEwIXk0tViJ6g8K7bJbWou/ZRM9y70v+V oGMMPaRQmT6cfBy1M7xwKIv0Q+cDwWcRBLmsMkAdMIaCNV7ZEZ7Z0q4Q+5N04XTobnuc BiUA== X-Gm-Message-State: AOAM533ENFD+syxJpju0BOKGG08vD1GEjxb07mQgbcuJbvemPgBtTKm+ 9SYahbJs1xOHecnaGoPQpI6cxA== X-Google-Smtp-Source: ABdhPJxrxO3JE2lo9DyPm/rsHp0OSHCELEbpqHbNk4WWhsdf9sJusVdL8alkbP2xCiUPZ8dWjmXo4w== X-Received: by 2002:a05:6602:24cf:: with SMTP id h15mr9828793ioe.8.1640713559093; Tue, 28 Dec 2021 09:45:59 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id s6sm11934908ild.5.2021.12.28.09.45.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Dec 2021 09:45:58 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id A412D800774; Tue, 28 Dec 2021 11:45:57 -0600 (CST) Date: Tue, 28 Dec 2021 11:45:57 -0600 From: Justin Pryzby To: Robert Haas Cc: Maciek Sakrejda , Tom Lane , Bharath Rupireddy , pgsql-hackers@lists.postgresql.org Subject: warn if GUC set to an invalid shared library Message-ID: <20211228174557.GI24477@telsasoft.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Y+xroYBkGM9OatJL" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Y+xroYBkGM9OatJL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline forking On Mon, Dec 13, 2021 at 09:01:57AM -0500, Robert Haas wrote: > On Thu, Dec 9, 2021 at 2:32 AM Maciek Sakrejda wrote: > > > Considering the vanishingly small number of actual complaints we've > > > seen about this, that sounds ridiculously over-engineered. > > > A documentation example should be sufficient. > > > > I don't know if this will tip the scales, but I'd like to lodge a > > belated complaint. I've gotten myself in this server-fails-to-start > > situation several times (in development, for what it's worth). The > > syntax (as Bharath pointed out in the original message) is pretty > > picky, there are no guard rails, and if you got there through ALTER > > SYSTEM, you can't fix it with ALTER SYSTEM (because the server isn't > > up). If you go to fix it manually, you get a scary "Do not edit this > > file manually!" warning that you have to know to ignore in this case > > (that's if you find the file after you realize what the fairly generic > > "FATAL: ... No such file or directory" error in the log is telling > > you). Plus you have to get the (different!) quoting syntax right or > > cut your losses and delete the change. > > +1. I disagree that trying to detect this kind of problem would be > "ridiculously over-engineered." I don't know whether it can be done > elegantly enough that we'd be happy with it and I don't know whether > it would end up just garden variety over-engineered. But there's > nothing ridiculous about trying to prevent people from putting their > system into a state where it won't start. > > (To be clear, I also think updating the documentation is sensible, > without taking a view on exactly what that update should look like.) Yea, I think documentation won't help to avoid this issue: If ALTER SYSTEM gives an ERROR, someone will likely to check the docs after a few minutes if they know that they didn't get the correct syntax. But if it gives no error nor warning, then most likely they won't know to check the docs. We should check session_preload_libraries too, right ? It's PGC_SIGHUP, so if someone sets the variable and sends sighup, clients will be rejected, and they had no good opportunity to avoid that. 0001 adds WARNINGs when doing SET: postgres=# SET local_preload_libraries=xyz; WARNING: could not load library: xyz: cannot open shared object file: No such file or directory SET postgres=# ALTER SYSTEM SET shared_preload_libraries =asdf; WARNING: could not load library: $libdir/plugins/asdf: cannot open shared object file: No such file or directory ALTER SYSTEM 0002 adds context when failing to start. 2021-12-27 17:01:12.996 CST postmaster[1403] WARNING: could not load library: $libdir/plugins/asdf: cannot open shared object file: No such file or directory 2021-12-27 17:01:14.938 CST postmaster[1403] FATAL: could not access file "asdf": No such file or directory 2021-12-27 17:01:14.938 CST postmaster[1403] CONTEXT: guc "shared_preload_libraries" 2021-12-27 17:01:14.939 CST postmaster[1403] LOG: database system is shut down But I wonder whether it'd be adequate context if dlopen were to fail rather than stat() ? Before 0003: 2021-12-18 23:13:57.861 CST postmaster[11956] FATAL: could not access file "asdf": No such file or directory 2021-12-18 23:13:57.862 CST postmaster[11956] LOG: database system is shut down After 0003: 2021-12-18 23:16:05.719 CST postmaster[13481] FATAL: could not load library: asdf: cannot open shared object file: No such file or directory 2021-12-18 23:16:05.720 CST postmaster[13481] LOG: database system is shut down -- Justin --Y+xroYBkGM9OatJL Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-warn-if-shared_preload_libraries-refers-to-an-nonext.patch"