Re: s/xlog/wal/ in tools and function names?

I've found myself wondering "where is my xlog" after running
pg_switch_xlog() in 10.0.

Renaming pg_xlog to pg_wal created inconsistency between tools, function
names and directory name on disk.

Should we also:

- rename pg_switch_xlog and friends to pg_switch_wal?
- rename pg_recievexlog to pg_revievewal (and others in bin/)?
- rename pg_xlogdump to pg_waldump?
- if we do rename, should we keep aliases for functions and symlinks for
tools?
- anything else?

--
Vladimir Rusinov
Storage SRE, Google Ireland

Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland
Registered in Dublin, Ireland
Registration Number: 368047

On Thu, Dec 1, 2016 at 10:29 AM, Vladimir Rusinov <vrusinov(at)google(dot)com> wrote:
> I've found myself wondering "where is my xlog" after running
> pg_switch_xlog() in 10.0.
>
> Renaming pg_xlog to pg_wal created inconsistency between tools, function
> names and directory name on disk.
>
> Should we also:
>
> - rename pg_switch_xlog and friends to pg_switch_wal?
> - rename pg_recievexlog to pg_revievewal (and others in bin/)?
> - rename pg_xlogdump to pg_waldump?

I think yes to all.

> - if we do rename, should we keep aliases for functions and symlinks for
> tools?

I think no.

> - anything else?

There are some SQL-callable functions that should probably be renamed
to match, too.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Fri, Dec 2, 2016 at 3:21 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Dec 1, 2016 at 10:29 AM, Vladimir Rusinov <vrusinov(at)google(dot)com> wrote:
>> I've found myself wondering "where is my xlog" after running
>> pg_switch_xlog() in 10.0.
>>
>> Renaming pg_xlog to pg_wal created inconsistency between tools, function
>> names and directory name on disk.
>>
>> Should we also:
>>
>> - rename pg_switch_xlog and friends to pg_switch_wal?
>> - rename pg_recievexlog to pg_revievewal (and others in bin/)?
>> - rename pg_xlogdump to pg_waldump?
>
> I think yes to all.

I was hesitant to propose that, but if there is a will do move
everything... Documentation would point to different pages if the
utilities are renamed, so that's not helpful when comparing features
across major releases... We may want to keep those files with their
historical names.

>> - if we do rename, should we keep aliases for functions and symlinks for
>> tools?
>
> I think no.

Better to do breakages in a single release rather than spreading them
across releases. While at it and because we are on a crazy trend, one
thing we could as well consider is removing pg_xlog_location_diff().
It has lost sense since pg_lsn has been introduced.

>> - anything else?
>
> There are some SQL-callable functions that should probably be renamed
> to match, too.

=# select proname from pg_proc where proname ~ 'xlog';
proname
---------------------------------
pg_current_xlog_location
pg_current_xlog_insert_location
pg_current_xlog_flush_location
pg_xlogfile_name_offset
pg_xlogfile_name
pg_xlog_location_diff
pg_last_xlog_receive_location
pg_last_xlog_replay_location
pg_is_xlog_replay_paused
pg_switch_xlog
pg_xlog_replay_pause
pg_xlog_replay_resume
(12 rows)
--
Michael

On Fri, Dec 2, 2016 at 2:02 AM Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Fri, Dec 2, 2016 at 3:21 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Thu, Dec 1, 2016 at 10:29 AM, Vladimir Rusinov <vrusinov(at)google(dot)com>
> wrote:
> >> I've found myself wondering "where is my xlog" after running
> >> pg_switch_xlog() in 10.0.
> >>
> >> Renaming pg_xlog to pg_wal created inconsistency between tools, function
> >> names and directory name on disk.
> >>
> >> Should we also:
> >>
> >> - rename pg_switch_xlog and friends to pg_switch_wal?
> >> - rename pg_recievexlog to pg_revievewal (and others in bin/)?
> >> - rename pg_xlogdump to pg_waldump?
> >
> > I think yes to all.
>
> I was hesitant to propose that, but if there is a will do move
> everything...

I'd like to see this happen, and sounds like so far there is a consensus
that it's a good idea.
Since I'm the one who proposed it, I can send out patches for some or maybe
even eventually all of them.

I guess it would make sense to do all of it in 10.0.
I'm new here, so not very sure about process. How many commit fests could I
expect before 10.0 is out (I'm a bit busy at the moment)?

> Documentation would point to different pages if the
> utilities are renamed, so that's not helpful when comparing features
> across major releases... We may want to keep those files with their
> historical names.
>

I'd rather have html redirects set up (assuming they are technically
possible).
In 10.0+ we'll have pg_receivexlog -> pg_receivewal, and we'll need to have
patches adding redirects pg_receivewal -> pg_receivexlog to older branches
so that people can jump between versions easily on the website.

>
> >> - if we do rename, should we keep aliases for functions and symlinks for
> >> tools?
> >
> > I think no.
>
> Better to do breakages in a single release rather than spreading them
> across releases. While at it and because we are on a crazy trend, one
> thing we could as well consider is removing pg_xlog_location_diff().
> It has lost sense since pg_lsn has been introduced.
>
> >> - anything else?
> >
> > There are some SQL-callable functions that should probably be renamed
> > to match, too.
>
> =# select proname from pg_proc where proname ~ 'xlog';
> proname
> ---------------------------------
> pg_current_xlog_location
> pg_current_xlog_insert_location
> pg_current_xlog_flush_location
> pg_xlogfile_name_offset
> pg_xlogfile_name
> pg_xlog_location_diff
> pg_last_xlog_receive_location
> pg_last_xlog_replay_location
> pg_is_xlog_replay_paused
> pg_switch_xlog
> pg_xlog_replay_pause
> pg_xlog_replay_resume
> (12 rows)
> --
> Michael
>

On Fri, Dec 2, 2016 at 8:28 PM, Vladimir Rusinov <vrusinov(at)google(dot)com> wrote:
> I guess it would make sense to do all of it in 10.0.
> I'm new here, so not very sure about process. How many commit fests could I
> expect before 10.0 is out (I'm a bit busy at the moment)?

There are two remaining: 2017-01 and 2017-03: https://commitfest.postgresql.org/

> I'd rather have html redirects set up (assuming they are technically
> possible).

That makes the most sense, and that would need some coordination with
the main documentation website to map a new page with the ones from
the previous versions.
--
Michael

On Fri, Dec 2, 2016 at 1:59 PM Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Fri, Dec 2, 2016 at 8:28 PM, Vladimir Rusinov <vrusinov(at)google(dot)com>
> wrote:
> > I guess it would make sense to do all of it in 10.0.
> > I'm new here, so not very sure about process. How many commit fests
> could I
> > expect before 10.0 is out (I'm a bit busy at the moment)?
>
> There are two remaining: 2017-01 and 2017-03:
> https://commitfest.postgresql.org/

Sweet, that's plenty of time.
Consider me signed up, probably by 2017-02 or 2017-03. If somebody else
wants to send some patches in this field earlier, please let me know so we
don't duplicate the work.

> > I'd rather have html redirects set up (assuming they are technically
> > possible).
>
> That makes the most sense, and that would need some coordination with
> the main documentation website to map a new page with the ones from
> the previous versions.
>

On 01-12-2016 23:02, Michael Paquier wrote:
>>> Should we also:
>>>
>>> - rename pg_switch_xlog and friends to pg_switch_wal?
>>> - rename pg_recievexlog to pg_revievewal (and others in bin/)?
>>> - rename pg_xlogdump to pg_waldump?
>>
>> I think yes to all.
>
+1.

> I was hesitant to propose that, but if there is a will do move
> everything... Documentation would point to different pages if the
> utilities are renamed, so that's not helpful when comparing features
> across major releases... We may want to keep those files with their
> historical names.
>
It seems confusing if we rename the tool but not the documentation file
name. Let's put a blinking message in the release notes saying 'tool X
was renamed to tool Y'. The only thing we should do is add on each tool
page something like: pg_waldump (formerly called pg_xlogdump) ...

>>> - if we do rename, should we keep aliases for functions and symlinks for
>>> tools?
>>
>> I think no.
>
+1. If the packager wants to do those aliases, it is up to him/her.

> =# select proname from pg_proc where proname ~ 'xlog';
> proname
> ---------------------------------
> pg_current_xlog_location
> pg_current_xlog_insert_location
> pg_current_xlog_flush_location
> pg_xlogfile_name_offset
> pg_xlogfile_name
> pg_xlog_location_diff
> pg_last_xlog_receive_location
> pg_last_xlog_replay_location
> pg_is_xlog_replay_paused
> pg_switch_xlog
> pg_xlog_replay_pause
> pg_xlog_replay_resume
> (12 rows)
>
In those cases, let's keep the functions as wrappers and undocumented.
In a few releases, we could remove them without breaking softwares that
rely on them.

--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento