Peter Eisentraut wrote: > You really have (at least) three options here: > > 1. Rename nothing > 2. Rename directory only > 3. Rename everything
I vote for 1) as I believe the renaming will create more confusion than it's worth, not even considering the renaming of functions and views. What if we look at the change from the pessimistic angle? An example of confusion that the change would create: a lot of users currently choose pg_wal for the destination directory of their archive command. Less-informed users that set up archiving and/or log shipping in PG10 based on advice online from previous versions will be fairly confused about the missing pg_xlog, and the fact that the pg_wal directory they're supposed to create already exists. Also googling for pg_wal, I'm finding food for thought like this IBM technote: http://www-01.ibm.com/support/docview.wss?uid=isg3T1015637 which recommends to "Remove all files under /var/lib/pgsql/9.0/data/pg_wal/" and also calls that directory the "write-ahead log directory" which is quite confusing because apparently it's the destination of their archive command. This brings the question: what about the people who will delete their pg_wal (ex-pg_xlog) when they face a disk-full condition and they mix up in their mind the archive directory and the WAL directory? It's hard to guess how many could make that mistake but I don't see why it would be less probable than confusing pg_xlog and pg_log. At least the contents of the latter directories look totally different, contrary to the wal directory versus wal archive. Also, what about the users who are helped currently by the fact that "pg_xlog" is associated at the top of google results to good articles that explain what it is, why it fills up and what to do about it? By burying the name "pg_xlog" we're also loosing that connection, and in the worst case making worse the problem we wanted to help with. There's also the disruption in existing backup scripts that directly reference pg_xlog. Obviously these scripts are critical, and there's something weird in breaking that intentionally. The motivation of the breakage is likely to be felt as frivolous and unfair to those people who are adversely impacted by the change, even if the part of not reading the release notes is their fault. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers