Re: Should pg_current_wal_location() become pg_current_wal_lsn()

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: david(dot)rowley(at)2ndquadrant(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Should pg_current_wal_location() become pg_current_wal_lsn()
Date: 2017-04-14 08:28:40
Message-ID: 20170414.172840.142892556.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Mon, 10 Apr 2017 19:26:11 +1200, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote in <CAKJS1f8O0njDKe8ePFQ-LK5-EjwThsDws6ohJ-+c6nWK+oUxtg(at)mail(dot)gmail(dot)com>
> ... and of course the other functions matching *wal*location*
>
> My thoughts here are that we're already breaking backward
> compatibility of these functions for PG10, so thought we might want to
> use this as an opportunity to fix the naming a bit more.
>
> I feel that the "location" word not the best choice. We also have a
> function called pg_tablespace_location() to give us the path that a
> tablespace is stored in, so I could understand anyone who's confused
> about what pg_current_wal_location() might do if they're looking at
> the function name only, and not the docs.
>
> For me, "lsn" suits these function names much better, so I'd like to
> see what other's think.
>
> It would be sad to miss this opportunity without at least discussing this first.
>
> The functions in question are:
>
> postgres=# \dfS *wal*location*
> List of functions
> Schema | Name | Result data type |
> Argument data types | Type
> ------------+--------------------------------+------------------+---------------------+--------
> pg_catalog | pg_current_wal_flush_location | pg_lsn |
> | normal
> pg_catalog | pg_current_wal_insert_location | pg_lsn |
> | normal
> pg_catalog | pg_current_wal_location | pg_lsn |
> | normal
> pg_catalog | pg_last_wal_receive_location | pg_lsn |
> | normal
> pg_catalog | pg_last_wal_replay_location | pg_lsn |
> | normal
> pg_catalog | pg_wal_location_diff | numeric |
> pg_lsn, pg_lsn | normal
> (6 rows)
>
> Opinions?

Similariliy, these columns may need renaming.

s=# select attname, attrelid::regclass from pg_attribute where attname like '%location%';
attname | attrelid
-----------------+---------------------
sent_location | pg_stat_replication
write_location | pg_stat_replication
flush_location | pg_stat_replication
replay_location | pg_stat_replication
(4 rows)

Currently the following functions and columns are using 'lsn'.

=# \dfS *lsn*
List of functions
Schema | Name | Result data type | Argument data types | Type
------------+-------------+------------------+---------------------+--------
pg_catalog | pg_lsn_cmp | integer | pg_lsn, pg_lsn | normal
pg_catalog | pg_lsn_eq | boolean | pg_lsn, pg_lsn | normal
...
pg_catalog | pg_lsn_recv | pg_lsn | internal | normal
pg_catalog | pg_lsn_send | bytea | pg_lsn | normal
(13 rows)

=# select distinct attname from pg_attribute where attname like '%lsn%';
attname
---------------------
confirmed_flush_lsn
latest_end_lsn
local_lsn
receive_start_lsn
received_lsn
remote_lsn
restart_lsn
srsublsn
(8 rows)

Feature is already frozen, but this seems inconsistent a bit..

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2017-04-14 10:18:27 Re: Interval for launching the table sync worker
Previous Message Yugo Nagata 2017-04-14 08:23:00 Re: [POC] hash partitioning