cutting down the TODO list thread - Mailing list pgsql-hackers

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.

**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

--
[1] https://www.postgresql.org/message-id/CAFBsxsHbqMzDoGB3eAGmpcpB%2B7uae%2BLLi_G%2Bo8HMEECM9CbQcQ%40mail.gmail.com

--