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 1kXUvE-0001yP-PY for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Oct 2020 19:46:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kXUvD-0003Qi-No for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Oct 2020 19:46:19 +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 1kXUvD-0003QB-HA for pgsql-hackers@lists.postgresql.org; Tue, 27 Oct 2020 19:46:19 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXUvB-0000tv-1Y for pgsql-hackers@postgresql.org; Tue, 27 Oct 2020 19:46:19 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1kXUv8-0003CY-Qx; Tue, 27 Oct 2020 15:46:14 -0400 Date: Tue, 27 Oct 2020 15:46:14 -0400 From: Bruce Momjian To: John Naylor Cc: pgsql-hackers Subject: Re: cutting down the TODO list thread Message-ID: <20201027194614.GR4951@momjian.us> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Oct 27, 2020 at 03:24:35PM -0400, John Naylor wrote: > As I mentioned in [1], I've volunteered to clear out the TODO list of items > that appear to be too difficult, controversial, or otherwise not worth doing to > warrant being listed there. I'll be working a few sections at a time, and every > so often I'll have a list of proposed items for removal. If I don't hear > objections, I'll remove the items after a few days while going through the next > set. > > Where there's an email thread, I've skimmed a few messages to get a sense of > the community's thoughts on it. Where easily determined, I've taken age into > account, insofar as something from 2017 is going to get much more benefit of > doubt than something from 2008. I've added after each item a phrase that sums > up the reason I believe it doesn't belong anymore. Feedback welcome, of course, > although I suspect there won't be much. Thanks for working on this. It certainly needs new eyes (not mine). ;-) I am fine reomving all the items below. I am kind of disappointed we have these _stuck_ items, but I don't see a clear way forward, so let's just remove them and see what requests we get for them. --------------------------------------------------------------------------- > **Administration > > - Have custom variables be transaction-safe >   Old and found to be difficult after attempting > > - Allow custom variables to appear in pg_settings() >   Old and controversial > > - Implement the SQL-standard mechanism whereby REVOKE ROLE revokes only the > privilege granted by the invoking role, and not those granted by other roles >   Old and difficult > > - Prevent query cancel packets from being replayed by an attacker, especially > when using SSL >   Old and difficult > > *Configuration files > > - Consider normalizing fractions in postgresql.conf, perhaps using '%' >   At the time (2007), some gucs used an actual percentage. > > - Add external tool to auto-tune some postgresql.conf parameters >   There are already out-of-core tools that try to do this. > > - Create utility to compute accurate random_page_cost value >   Seems outdated: In the current age of SSDs and cloud environments, it's often > just set to 1.1, and there hasn't been a demand to be more accurate than that. > > - Allow synchronous_standby_names to be disabled after communication failure > with all synchronous standby servers exceeds some timeout >   Controversial > > - Adjust rounding behavior for numeric GUC values >   Controversial > > *Tablespaces > > - Allow WAL replay of CREATE TABLESPACE to work when the directory structure on > the recovery computer is different from the original >   Thread quote: "part of the difficult, perhaps-not-worth doing impossible > problems" > > - Allow per-tablespace quotas >   This seems to point to the larger problem space of disk space monitoring, and > should probably be phrased thusly, and is a much bigger project or set of > projects. > > - Allow tablespaces on RAM-based partitions for temporary objects >   In the thread, what's desired is the ability to have some amount of > durability on a RAM-disk without WAL logging. > > - Close race in DROP TABLESPACE on Windows >   This refers to buildfarm failures from 2014. > > *Statistics Collector > > - Track number of WAL files ready to be archived in pg_stat_archiver >   Thread quote: "pg_stat_archiver already has a column for last_archived_wal > and last_failed_wal, so you can already work out how many files there must be > between then and now" > > *Point-In-Time Recovery > > - Allow archive_mode to be changed without server restart >   Controversial and old > > *Standby server mode > > - Allow pg_xlogfile_name() to be used in recovery mode >   Controversial and old > > - Change walsender so that it applies per-role settings >   Old and possibly obsolete -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee