Should pg_current_wal_location() become pg_current_wal_lsn()
... 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?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
At Mon, 10 Apr 2017 19:26:11 +1200, David Rowley <david.rowley@2ndquadrant.com> wrote in <CAKJS1f8O0njDKe8ePFQ-LK5-EjwThsDws6ohJ-+c6nWK+oUxtg@mail.gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Apr 14, 2017 at 4:28 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
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)
Personally, I would be inclined not to tinker with this, not just
because we're after freeze but because it doesn't seem like an
improvement to me. Referring to an LSN as location seems fine to me;
I mean, granted, it's one specific kind of location, but that doesn't
make it wrong. If somebody calls you and says "let's meet up", and
you say "sure, what's your location?" they might give you a street
address or GPS coordinates or the name of a nearby point of interest,
depending on what information they have easily available, but that's
cool; those things all let you find them. Similarly, an LSN lets you
find a particular point within a WAL stream, but I don't think that
makes it not a location.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Fri, Apr 14, 2017 at 4:28 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:Similariliy, these columns may need renaming.
Personally, I would be inclined not to tinker with this, not just
because we're after freeze but because it doesn't seem like an
improvement to me. Referring to an LSN as location seems fine to me;
I mean, granted, it's one specific kind of location, but that doesn't
make it wrong.
In a green field it would be perfectly fine --- but I think Kyotaro-san's
point is about consistency. If all the other exposed names that involve
the same concept use "lsn", then it's fair to say that it's a bad idea
for these four column names to be randomly different from the rest.
Now this is a pre-existing problem: those column names existed in 9.6,
and so did some of the ones named using "lsn". But we've added more
of the latter in v10. I think the real problem right now is that nobody
has a rule to follow about which way to name new exposed references to
the concept, and that's simply bad.
It's possible that we should say that backwards compatibility outweighs
consistency and therefore it's too late to change these names. But
I think your argument above is missing the point.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Apr 14, 2017 at 10:22:36AM -0400, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Fri, Apr 14, 2017 at 4:28 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:Similariliy, these columns may need renaming.
Personally, I would be inclined not to tinker with this, not just
because we're after freeze but because it doesn't seem like an
improvement to me. Referring to an LSN as location seems fine to me;
I mean, granted, it's one specific kind of location, but that doesn't
make it wrong.In a green field it would be perfectly fine --- but I think Kyotaro-san's
point is about consistency. If all the other exposed names that involve
the same concept use "lsn", then it's fair to say that it's a bad idea
for these four column names to be randomly different from the rest.Now this is a pre-existing problem: those column names existed in 9.6,
and so did some of the ones named using "lsn". But we've added more
of the latter in v10. I think the real problem right now is that nobody
has a rule to follow about which way to name new exposed references to
the concept, and that's simply bad.It's possible that we should say that backwards compatibility outweighs
consistency and therefore it's too late to change these names. But
I think your argument above is missing the point.
Yeah, this area is complex enough so any consistency we can add helps.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Fri, Apr 14, 2017 at 4:28 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:Similariliy, these columns may need renaming.
Personally, I would be inclined not to tinker with this, not just
because we're after freeze but because it doesn't seem like an
improvement to me. Referring to an LSN as location seems fine to me;
I mean, granted, it's one specific kind of location, but that doesn't
make it wrong.In a green field it would be perfectly fine --- but I think Kyotaro-san's
point is about consistency. If all the other exposed names that involve
the same concept use "lsn", then it's fair to say that it's a bad idea
for these four column names to be randomly different from the rest.Now this is a pre-existing problem: those column names existed in 9.6,
and so did some of the ones named using "lsn". But we've added more
of the latter in v10. I think the real problem right now is that nobody
has a rule to follow about which way to name new exposed references to
the concept, and that's simply bad.It's possible that we should say that backwards compatibility outweighs
consistency and therefore it's too late to change these names. But
I think your argument above is missing the point.
I agree and definitely view 'lsn' as better than just 'location' when
we're talking about an lsn. The datatype is 'pg_lsn', let's use 'lsn'
whenever that's what it is. Consistency here is really good.
Thanks!
Stephen
On 4/14/17 04:28, Kyotaro HORIGUCHI wrote:
=# 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..
I think these are all recently added for logical replication. We could
rename them to _location.
I'm not a fan of renaming everything the opposite way.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 4/14/17 11:36, Bruce Momjian wrote:
Yeah, this area is complex enough so any consistency we can add helps.
If we're talking about making things easier to understand, wouldn't a
random user rather know what a WAL "location" is instead of a WAL "LSN"?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
If we're talking about making things easier to understand, wouldn't a
random user rather know what a WAL "location" is instead of a WAL "LSN"?
I wouldn't object to standardizing on "location" instead of "lsn" in the
related function and column names. What I don't like is using different
words for the same thing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
If we're talking about making things easier to understand, wouldn't a
random user rather know what a WAL "location" is instead of a WAL "LSN"?I wouldn't object to standardizing on "location" instead of "lsn" in the
related function and column names. What I don't like is using different
words for the same thing.
The case mentioned in the subject of this thread has been using the
word "location" since time immemorial. It's true that we've already
renamed it (xlog -> wal) in this release, so if we want to standardize
on lsn, now's certainly the time to do it. I'm worried that
pg_current_wal_lsn() is an identifier composed almost entirely of
abbreviations and therefore possibly just as impenetrable as
qx_current_pfq_dnr(), but maybe we should assume that LSN is a term of
art with which knowledgeable users are required to be familiar, much
as we are doing for "WAL".
It appears, from grepping the 9.6 version of pg_proc.h, that both lsn
and location have some historical precedent.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
At Fri, 14 Apr 2017 18:26:37 -0400, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote in <052f4ce0-159a-1666-f136-91977d3267a5@2ndquadrant.com>
On 4/14/17 04:28, Kyotaro HORIGUCHI wrote:
=# 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..
I think these are all recently added for logical replication. We could
rename them to _location.I'm not a fan of renaming everything the opposite way.
I don't particulary care for either. What is most unpleasant here
for me is the inconsistency among several replication-related
tables. Logical replication stuff is using LSN and physical sutff
has been using location, but pg_stat_wal_receiver is using
LSN. pg_replication_slots as the common stuff is using LSN.
"Location" fits attribute names since the table name implies that
the location is "LSN".
On the other hand nothing suggests such implication on function
names. So only "wal_location" or "lsn" can be used in function
names. pg_current_wal_* requires to be "wal_lsn" even using LSN
since "LSN" itself doesn't imply WAL files being
written. "wal_lsn" looks somewhat too-much, though.
Columns:
=# select attrelid::regclass || '.' || attname from pg_attribute where attname like '%location%' or attname like '%lsn%';
?column?
------------------------------------------
pg_subscription_rel.srsublsn
pg_stat_replication.sent_location
pg_stat_replication.write_location
pg_stat_replication.flush_location
pg_stat_replication.replay_location
pg_stat_wal_receiver.receive_start_lsn
pg_stat_wal_receiver.received_lsn
pg_stat_wal_receiver.latest_end_lsn
pg_stat_subscription.received_lsn
pg_stat_subscription.latest_end_lsn
pg_replication_slots.restart_lsn
pg_replication_slots.confirmed_flush_lsn
pg_replication_origin_status.remote_lsn
pg_replication_origin_status.local_lsn
pg_subscription_rel has a bit different naming convention from
others. But I'm not sure that involving it in the unification is
good since it doesn't seem to be explicitly exposed to users.
=# select proname from pg_proc where proname like '%location%' or proname like '%lsn%';
proname
--------------------------------
pg_tablespace_location ## This is irrelevant
pg_current_wal_location
pg_current_wal_insert_location
pg_current_wal_flush_location
pg_wal_location_diff
pg_last_wal_receive_location
pg_last_wal_replay_location
pg_lsn_mi
pg_lsn_in
pg_lsn_out
pg_lsn_lt
pg_lsn_le
pg_lsn_eq
pg_lsn_ge
pg_lsn_gt
pg_lsn_ne
pg_lsn_recv
pg_lsn_send
pg_lsn_cmp
pg_lsn_hash
I think we can use "location" for all attributes and functions
except pg_lsn operators.
The last annoyance would be pg_wal_location_diff(). This exists
only for backward compatibility but the name 'pg_wal_lsn_diff' is
already so far from the original name that it becomes totally
useless.
Any more thoughts?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
At Sat, 15 Apr 2017 12:56:32 -0400, Robert Haas <robertmhaas@gmail.com> wrote in <CA+TgmoZjDo9ckxf6aYrqyMoiSw5yfBB2gpMbrBtE9zr==uczhw@mail.gmail.com>
On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
If we're talking about making things easier to understand, wouldn't a
random user rather know what a WAL "location" is instead of a WAL "LSN"?I wouldn't object to standardizing on "location" instead of "lsn" in the
related function and column names. What I don't like is using different
words for the same thing.The case mentioned in the subject of this thread has been using the
word "location" since time immemorial. It's true that we've already
renamed it (xlog -> wal) in this release, so if we want to standardize
on lsn, now's certainly the time to do it. I'm worried that
pg_current_wal_lsn() is an identifier composed almost entirely of
abbreviations and therefore possibly just as impenetrable as
qx_current_pfq_dnr(), but maybe we should assume that LSN is a term of
art with which knowledgeable users are required to be familiar, much
as we are doing for "WAL".It appears, from grepping the 9.6 version of pg_proc.h, that both lsn
and location have some historical precedent.
I'd better to have replied here. The detail is in my reply on
another brandh of this thread.
/messages/by-id/20170417.143937.232025253.horiguchi.kyotaro@lab.ntt.co.jp
After all, "location" seems better to me in user interface. We
could rename almost all of %lsn% names into %location% except
pg_lsn oprators as long as it doesn't become too long or complex.
One annoyance is the historical function pg_xlog_location_diff(),
which is currently just an alias of pg_lsn_mi. It is
substantially an operator, but 'pg_wal_lsn_diff()' is so far from
the historical name that it becomes totally useless.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 4/15/17 12:56 PM, Robert Haas wrote:
On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
If we're talking about making things easier to understand, wouldn't a
random user rather know what a WAL "location" is instead of a WAL "LSN"?I wouldn't object to standardizing on "location" instead of "lsn" in the
related function and column names. What I don't like is using different
words for the same thing.The case mentioned in the subject of this thread has been using the
word "location" since time immemorial. It's true that we've already
renamed it (xlog -> wal) in this release, so if we want to standardize
on lsn, now's certainly the time to do it. I'm worried that
pg_current_wal_lsn() is an identifier composed almost entirely of
abbreviations and therefore possibly just as impenetrable as
qx_current_pfq_dnr(), but maybe we should assume that LSN is a term of
art with which knowledgeable users are required to be familiar, much
as we are doing for "WAL".
+1, and I'm in favor of using "lsn" wherever applicable. It seems to me
that if a user calls a function (or queries a table) that returns an lsn
then they should be aware of what an lsn is.
--
-David
david@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 19 April 2017 at 03:33, David Steele <david@pgmasters.net> wrote:
+1, and I'm in favor of using "lsn" wherever applicable. It seems to me
that if a user calls a function (or queries a table) that returns an lsn
then they should be aware of what an lsn is.
OK, so I've read over this thread again and I think it's time to
summarise the votes:
It seem that;
Robert mentions he'd be inclined not to tinker with this, but mentions
nothing of inconsistency.
Bruce mentions he'd like consistency but does not mention which he'd prefer.
Stephen wants consistency and votes to change "location" to "lsn" in
regards to a pg_lsn.
Peter would rather see use of "location", mentions about changing the
new in v10 stuff, but not about the existing 9.6 usages of lsn in
column names
Tom would not object to use of "location" over "lsn".
Kyotaro would rather see the use of "location" for all apart from the
pg_lsn operator functions. Unsure how we handle pg_wal_location_diff()
David Steel would rather see this changed to use "lsn" instead of location.
So in summary, nobody apart from Robert appeared to have any concerns
over breaking backward compatibility.
In favour of "location" -> "lsn": Stephen, David Steel,
In favour of "lsn" -> "location": Peter, Tom, Kyotaro
I left Bruce out since he just voted for consistency.
So "lsn" -> "location" seems to be winning
Is that enough to proceed?
Anyone else?
The patch to do this should likely also include a regression test to
ensure nothing new creeps in which breaks the new standard.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
OK, so I've read over this thread again and I think it's time to
summarise the votes:
...
In favour of "location" -> "lsn": Stephen, David Steel,
In favour of "lsn" -> "location": Peter, Tom, Kyotaro
FWIW, I was not voting in favor of "location"; I was just saying that
I wanted consistency. If we're voting which way to move, please count
me as a vote for "lsn".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 19 April 2017 at 15:31, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Rowley <david.rowley@2ndquadrant.com> writes:
OK, so I've read over this thread again and I think it's time to
summarise the votes:
...
In favour of "location" -> "lsn": Stephen, David Steel,
In favour of "lsn" -> "location": Peter, Tom, KyotaroFWIW, I was not voting in favor of "location"; I was just saying that
I wanted consistency. If we're voting which way to move, please count
me as a vote for "lsn".
Updated votes:
In favour of "location" -> "lsn": Tom, Stephen, David Steel
In favour of "lsn" -> "location": Peter, Kyotaro
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 19, 2017 at 12:36 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
In favour of "location" -> "lsn": Tom, Stephen, David Steel
In favour of "lsn" -> "location": Peter, Kyotaro
I vote for "location" -> "lsn". I would expect complains about the
current inconsistency at some point, and the function names have been
already changed for this release..
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
At Wed, 19 Apr 2017 13:32:48 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in <CAB7nPqR=jHB2Eh0r6bjcExsU_qkdWFyo23coxBt325aHmcSiuw@mail.gmail.com>
On Wed, Apr 19, 2017 at 12:36 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:In favour of "location" -> "lsn": Tom, Stephen, David Steel
In favour of "lsn" -> "location": Peter, KyotaroI vote for "location" -> "lsn". I would expect complains about the
current inconsistency at some point, and the function names have been
already changed for this release..
I won't stick on "location" except that "pg_wal_lsn_diff" seems
no longer useful.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2017-04-19 1:32 GMT-03:00 Michael Paquier <michael.paquier@gmail.com>:
I vote for "location" -> "lsn". I would expect complains about the
current inconsistency at some point, and the function names have been
already changed for this release..
+1.
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
<http://www.timbira.com.br>
On 20 April 2017 at 07:29, Euler Taveira <euler@timbira.com.br> wrote:
2017-04-19 1:32 GMT-03:00 Michael Paquier <michael.paquier@gmail.com>:
I vote for "location" -> "lsn". I would expect complains about the
current inconsistency at some point, and the function names have been
already changed for this release..
OK, so I've created a draft patch which does this.
In summary of what it does
1. Renames all wal_location functions to wal_lsn.
2. Renames all system view columns to use "lsn" instead of "location"
3. Rename function parameters to use "lsn" instead of "location".
4. Rename function parameters "wal_position" to "lsn". (Not mentioned
before, but seems consistency was high on the list from earlier
comments on the thread)
5. Change documentation to reflect the above changes.
6. Fix bug where docs claimed return type of
pg_logical_slot_peek_changes.location was text, when it was pg_lsn
(maybe apply separately?)
7. Change some places in the func.sgml where it was referring to the
lsn as a "position" rather than "location". (We want consistency here)
Is this touching all places which were mentioned by everyone?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachments:
location2lsn_rename.patchapplication/octet-stream; name=location2lsn_rename.patchDownload
diff --git a/contrib/bloom/t/001_wal.pl b/contrib/bloom/t/001_wal.pl
index dc907ba..dbba198 100644
--- a/contrib/bloom/t/001_wal.pl
+++ b/contrib/bloom/t/001_wal.pl
@@ -16,7 +16,7 @@ sub test_index_replay
# Wait for standby to catch up
my $applname = $node_standby->name;
my $caughtup_query =
-"SELECT pg_current_wal_location() <= write_location FROM pg_stat_replication WHERE application_name = '$applname';";
+"SELECT pg_current_wal_lsn() <= write_lsn FROM pg_stat_replication WHERE application_name = '$applname';";
$node_master->poll_query_until('postgres', $caughtup_query)
or die "Timed out while waiting for standby 1 to catch up";
diff --git a/contrib/test_decoding/expected/ddl.out b/contrib/test_decoding/expected/ddl.out
index 275c84a..1e22c1e 100644
--- a/contrib/test_decoding/expected/ddl.out
+++ b/contrib/test_decoding/expected/ddl.out
@@ -58,7 +58,7 @@ SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot', 'test_d
SELECT slot_name, plugin, slot_type, active,
NOT catalog_xmin IS NULL AS catalog_xmin_set,
xmin IS NULl AS data_xmin_not_set,
- pg_wal_location_diff(restart_lsn, '0/01000000') > 0 AS some_wal
+ pg_wal_lsn_diff(restart_lsn, '0/01000000') > 0 AS some_wal
FROM pg_replication_slots;
slot_name | plugin | slot_type | active | catalog_xmin_set | data_xmin_not_set | some_wal
-----------------+---------------+-----------+--------+------------------+-------------------+----------
diff --git a/contrib/test_decoding/sql/ddl.sql b/contrib/test_decoding/sql/ddl.sql
index 49dad39..057dae0 100644
--- a/contrib/test_decoding/sql/ddl.sql
+++ b/contrib/test_decoding/sql/ddl.sql
@@ -29,7 +29,7 @@ SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot', 'test_d
SELECT slot_name, plugin, slot_type, active,
NOT catalog_xmin IS NULL AS catalog_xmin_set,
xmin IS NULl AS data_xmin_not_set,
- pg_wal_location_diff(restart_lsn, '0/01000000') > 0 AS some_wal
+ pg_wal_lsn_diff(restart_lsn, '0/01000000') > 0 AS some_wal
FROM pg_replication_slots;
/*
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index f06d0a9..f9d0452 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17890,17 +17890,17 @@ SELECT collation for ('foo' COLLATE "de_DE");
<tbody>
<row>
- <entry><literal>checkpoint_location</literal></entry>
+ <entry><literal>checkpoint_lsn</literal></entry>
<entry><type>pg_lsn</type></entry>
</row>
<row>
- <entry><literal>prior_location</literal></entry>
+ <entry><literal>prior_lsn</literal></entry>
<entry><type>pg_lsn</type></entry>
</row>
<row>
- <entry><literal>redo_location</literal></entry>
+ <entry><literal>redo_lsn</literal></entry>
<entry><type>pg_lsn</type></entry>
</row>
@@ -18128,7 +18128,7 @@ SELECT collation for ('foo' COLLATE "de_DE");
<tbody>
<row>
- <entry><literal>min_recovery_end_location</literal></entry>
+ <entry><literal>min_recovery_end_lsn</literal></entry>
<entry><type>pg_lsn</type></entry>
</row>
@@ -18138,12 +18138,12 @@ SELECT collation for ('foo' COLLATE "de_DE");
</row>
<row>
- <entry><literal>backup_start_location</literal></entry>
+ <entry><literal>backup_start_lsn</literal></entry>
<entry><type>pg_lsn</type></entry>
</row>
<row>
- <entry><literal>backup_end_location</literal></entry>
+ <entry><literal>backup_end_lsn</literal></entry>
<entry><type>pg_lsn</type></entry>
</row>
@@ -18386,13 +18386,13 @@ SELECT set_config('log_statement_stats', 'off', false);
<primary>pg_create_restore_point</primary>
</indexterm>
<indexterm>
- <primary>pg_current_wal_flush_location</primary>
+ <primary>pg_current_wal_flush_lsn</primary>
</indexterm>
<indexterm>
- <primary>pg_current_wal_insert_location</primary>
+ <primary>pg_current_wal_insert_lsn</primary>
</indexterm>
<indexterm>
- <primary>pg_current_wal_location</primary>
+ <primary>pg_current_wal_lsn</primary>
</indexterm>
<indexterm>
<primary>pg_start_backup</primary>
@@ -18416,7 +18416,7 @@ SELECT set_config('log_statement_stats', 'off', false);
<primary>pg_walfile_name_offset</primary>
</indexterm>
<indexterm>
- <primary>pg_wal_location_diff</primary>
+ <primary>pg_wal_lsn_diff</primary>
</indexterm>
<para>
@@ -18424,7 +18424,7 @@ SELECT set_config('log_statement_stats', 'off', false);
linkend="functions-admin-backup-table"> assist in making on-line backups.
These functions cannot be executed during recovery (except
<function>pg_is_in_backup</function>, <function>pg_backup_start_time</function>
- and <function>pg_wal_location_diff</function>).
+ and <function>pg_wal_lsn_diff</function>).
</para>
<table id="functions-admin-backup-table">
@@ -18445,21 +18445,21 @@ SELECT set_config('log_statement_stats', 'off', false);
</row>
<row>
<entry>
- <literal><function>pg_current_wal_flush_location()</function></literal>
+ <literal><function>pg_current_wal_flush_lsn()</function></literal>
</entry>
<entry><type>pg_lsn</type></entry>
<entry>Get current transaction log flush location</entry>
</row>
<row>
<entry>
- <literal><function>pg_current_wal_insert_location()</function></literal>
+ <literal><function>pg_current_wal_insert_lsn()</function></literal>
</entry>
<entry><type>pg_lsn</type></entry>
<entry>Get current transaction log insert location</entry>
</row>
<row>
<entry>
- <literal><function>pg_current_wal_location()</function></literal>
+ <literal><function>pg_current_wal_lsn()</function></literal>
</entry>
<entry><type>pg_lsn</type></entry>
<entry>Get current transaction log write location</entry>
@@ -18508,21 +18508,21 @@ SELECT set_config('log_statement_stats', 'off', false);
</row>
<row>
<entry>
- <literal><function>pg_walfile_name(<parameter>location</> <type>pg_lsn</>)</function></literal>
+ <literal><function>pg_walfile_name(<parameter>lsn</> <type>pg_lsn</>)</function></literal>
</entry>
<entry><type>text</type></entry>
- <entry>Convert transaction log location string to file name</entry>
+ <entry>Convert transaction log location to file name</entry>
</row>
<row>
<entry>
- <literal><function>pg_walfile_name_offset(<parameter>location</> <type>pg_lsn</>)</function></literal>
+ <literal><function>pg_walfile_name_offset(<parameter>lsn</> <type>pg_lsn</>)</function></literal>
</entry>
<entry><type>text</>, <type>integer</></entry>
- <entry>Convert transaction log location string to file name and decimal byte offset within file</entry>
+ <entry>Convert transaction log location to file name and decimal byte offset within file</entry>
</row>
<row>
<entry>
- <literal><function>pg_wal_location_diff(<parameter>location</> <type>pg_lsn</>, <parameter>location</> <type>pg_lsn</>)</function></literal>
+ <literal><function>pg_wal_lsn_diff(<parameter>lsn</> <type>pg_lsn</>, <parameter>lsn</> <type>pg_lsn</>)</function></literal>
</entry>
<entry><type>numeric</></entry>
<entry>Calculate the difference between two transaction log locations</entry>
@@ -18605,10 +18605,10 @@ postgres=# select pg_start_backup('label_goes_here');
</para>
<para>
- <function>pg_current_wal_location</> displays the current transaction log write
+ <function>pg_current_wal_lsn</> displays the current transaction log write
location in the same format used by the above functions. Similarly,
- <function>pg_current_wal_insert_location</> displays the current transaction log
- insertion point and <function>pg_current_wal_flush_location</> displays the
+ <function>pg_current_wal_insert_lsn</> displays the current transaction log
+ insertion point and <function>pg_current_wal_flush_lsn</> displays the
current transaction log flush point. The insertion point is the <quote>logical</>
end of the transaction log at any instant, while the write location is the end of
what has actually been written out from the server's internal buffers and flush
@@ -18640,7 +18640,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
</para>
<para>
- <function>pg_wal_location_diff</> calculates the difference in bytes
+ <function>pg_wal_lsn_diff</> calculates the difference in bytes
between two transaction log locations. It can be used with
<structname>pg_stat_replication</structname> or some functions shown in
<xref linkend="functions-admin-backup-table"> to get the replication lag.
@@ -18660,10 +18660,10 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
<primary>pg_is_in_recovery</primary>
</indexterm>
<indexterm>
- <primary>pg_last_wal_receive_location</primary>
+ <primary>pg_last_wal_receive_lsn</primary>
</indexterm>
<indexterm>
- <primary>pg_last_wal_replay_location</primary>
+ <primary>pg_last_wal_replay_lsn</primary>
</indexterm>
<indexterm>
<primary>pg_last_xact_replay_timestamp</primary>
@@ -18695,7 +18695,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
</row>
<row>
<entry>
- <literal><function>pg_last_wal_receive_location()</function></literal>
+ <literal><function>pg_last_wal_receive_lsn()</function></literal>
</entry>
<entry><type>pg_lsn</type></entry>
<entry>Get last transaction log location received and synced to disk by
@@ -18709,7 +18709,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
</row>
<row>
<entry>
- <literal><function>pg_last_wal_replay_location()</function></literal>
+ <literal><function>pg_last_wal_replay_lsn()</function></literal>
</entry>
<entry><type>pg_lsn</type></entry>
<entry>Get last transaction log location replayed during recovery.
@@ -18932,7 +18932,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
<literal><function>pg_create_physical_replication_slot(<parameter>slot_name</parameter> <type>name</type> <optional>, <parameter>immediately_reserve</> <type>boolean</>, <parameter>temporary</> <type>boolean</></optional>)</function></literal>
</entry>
<entry>
- (<parameter>slot_name</parameter> <type>name</type>, <parameter>wal_position</parameter> <type>pg_lsn</type>)
+ (<parameter>slot_name</parameter> <type>name</type>, <parameter>lsn</parameter> <type>pg_lsn</type>)
</entry>
<entry>
Creates a new physical replication slot named
@@ -18977,7 +18977,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
<literal><function>pg_create_logical_replication_slot(<parameter>slot_name</parameter> <type>name</type>, <parameter>plugin</parameter> <type>name</type> <optional>, <parameter>temporary</> <type>boolean</></optional>)</function></literal>
</entry>
<entry>
- (<parameter>slot_name</parameter> <type>name</type>, <parameter>wal_position</parameter> <type>pg_lsn</type>)
+ (<parameter>slot_name</parameter> <type>name</type>, <parameter>lsn</parameter> <type>pg_lsn</type>)
</entry>
<entry>
Creates a new logical (decoding) replication slot named
@@ -19000,7 +19000,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
<literal><function>pg_logical_slot_get_changes(<parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
</entry>
<entry>
- (<parameter>location</parameter> <type>pg_lsn</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>text</type>)
+ (<parameter>lsn</parameter> <type>pg_lsn</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>text</type>)
</entry>
<entry>
Returns changes in the slot <parameter>slot_name</parameter>, starting
@@ -19025,7 +19025,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
<literal><function>pg_logical_slot_peek_changes(<parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
</entry>
<entry>
- (<parameter>location</parameter> <type>text</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>text</type>)
+ (<parameter>lsn</parameter> <type>pg_lsn</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>text</type>)
</entry>
<entry>
Behaves just like
@@ -19043,7 +19043,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
<literal><function>pg_logical_slot_get_binary_changes(<parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
</entry>
<entry>
- (<parameter>location</parameter> <type>pg_lsn</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>bytea</type>)
+ (<parameter>lsn</parameter> <type>pg_lsn</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>bytea</type>)
</entry>
<entry>
Behaves just like
@@ -19060,7 +19060,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
<literal><function>pg_logical_slot_peek_binary_changes(<parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
</entry>
<entry>
- (<parameter>location</parameter> <type>pg_lsn</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>bytea</type>)
+ (<parameter>lsn</parameter> <type>pg_lsn</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>bytea</type>)
</entry>
<entry>
Behaves just like
@@ -19179,7 +19179,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
<type>pg_lsn</type>
</entry>
<entry>
- Return the replay position for the replication origin configured in
+ Return the replay location for the replication origin configured in
the current session. The parameter <parameter>flush</parameter>
determines whether the corresponding local transaction will be
guaranteed to have been flushed to disk or not.
@@ -19226,15 +19226,15 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
<indexterm>
<primary>pg_replication_origin_advance</primary>
</indexterm>
- <literal>pg_replication_origin_advance<function>(<parameter>node_name</parameter> <type>text</type>, <parameter>pos</parameter> <type>pg_lsn</type>)</function></literal>
+ <literal>pg_replication_origin_advance<function>(<parameter>node_name</parameter> <type>text</type>, <parameter>lsn</parameter> <type>pg_lsn</type>)</function></literal>
</entry>
<entry>
<type>void</>
</entry>
<entry>
Set replication progress for the given node to the given
- position. This primarily is useful for setting up the initial position
- or a new position after configuration changes and similar. Be aware
+ location. This primarily is useful for setting up the initial location
+ or a new location after configuration changes and similar. Be aware
that careless use of this function can lead to inconsistently
replicated data.
</entry>
@@ -19251,7 +19251,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
<type>pg_lsn</type>
</entry>
<entry>
- Return the replay position for the given replication origin. The
+ Return the replay location for the given replication origin. The
parameter <parameter>flush</parameter> determines whether the
corresponding local transaction will be guaranteed to have been
flushed to disk or not.
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 9e2be5f..c5e3a08 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -851,8 +851,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
standby. You can calculate this lag by comparing the current WAL write
location on the primary with the last WAL location received by the
standby. They can be retrieved using
- <function>pg_current_wal_location</> on the primary and the
- <function>pg_last_wal_receive_location</> on the standby,
+ <function>pg_current_wal_lsn</> on the primary and the
+ <function>pg_last_wal_receive_lsn</> on the standby,
respectively (see <xref linkend="functions-admin-backup-table"> and
<xref linkend="functions-recovery-info-table"> for details).
The last WAL receive location in the standby is also displayed in the
@@ -863,10 +863,10 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
You can retrieve a list of WAL sender processes via the
<link linkend="monitoring-stats-views-table">
<literal>pg_stat_replication</></link> view. Large differences between
- <function>pg_current_wal_location</> and <literal>sent_location</> field
+ <function>pg_current_wal_lsn</> and <literal>sent_lsn</> field
might indicate that the master server is under heavy load, while
- differences between <literal>sent_location</> and
- <function>pg_last_wal_receive_location</> on the standby might indicate
+ differences between <literal>sent_lsn</> and
+ <function>pg_last_wal_receive_lsn</> on the standby might indicate
network delay, or that the standby is under heavy load.
</para>
</sect3>
@@ -927,8 +927,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
You can create a replication slot like this:
<programlisting>
postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
- slot_name | wal_position
--------------+---------------
+ slot_name | lsn
+-------------+-----
node_a_slot |
postgres=# SELECT * FROM pg_replication_slots;
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index bb22f9a..2683e2e 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -56,8 +56,8 @@
<programlisting>
postgres=# -- Create a slot named 'regression_slot' using the output plugin 'test_decoding'
postgres=# SELECT * FROM pg_create_logical_replication_slot('regression_slot', 'test_decoding');
- slot_name | wal_position
------------------+---------------
+ slot_name | lsn
+-----------------+-----------
regression_slot | 0/16B1970
(1 row)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 2a83671..65d3086 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -1694,26 +1694,26 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</entry>
</row>
<row>
- <entry><structfield>sent_location</></entry>
+ <entry><structfield>sent_lsn</></entry>
<entry><type>pg_lsn</></entry>
- <entry>Last transaction log position sent on this connection</entry>
+ <entry>Last transaction log location sent on this connection</entry>
</row>
<row>
- <entry><structfield>write_location</></entry>
+ <entry><structfield>write_lsn</></entry>
<entry><type>pg_lsn</></entry>
- <entry>Last transaction log position written to disk by this standby
+ <entry>Last transaction log location written to disk by this standby
server</entry>
</row>
<row>
- <entry><structfield>flush_location</></entry>
+ <entry><structfield>flush_lsn</></entry>
<entry><type>pg_lsn</></entry>
- <entry>Last transaction log position flushed to disk by this standby
+ <entry>Last transaction log location flushed to disk by this standby
server</entry>
</row>
<row>
- <entry><structfield>replay_location</></entry>
+ <entry><structfield>replay_lsn</></entry>
<entry><type>pg_lsn</></entry>
- <entry>Last transaction log position replayed into the database on this
+ <entry>Last transaction log location replayed into the database on this
standby server</entry>
</row>
<row>
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 5041f0e..aa47b0d 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -351,7 +351,7 @@ pg_create_restore_point(PG_FUNCTION_ARGS)
* to the kernel, but is not necessarily synced to disk.
*/
Datum
-pg_current_wal_location(PG_FUNCTION_ARGS)
+pg_current_wal_lsn(PG_FUNCTION_ARGS)
{
XLogRecPtr current_recptr;
@@ -372,7 +372,7 @@ pg_current_wal_location(PG_FUNCTION_ARGS)
* This function is mostly for debugging purposes.
*/
Datum
-pg_current_wal_insert_location(PG_FUNCTION_ARGS)
+pg_current_wal_insert_lsn(PG_FUNCTION_ARGS)
{
XLogRecPtr current_recptr;
@@ -393,7 +393,7 @@ pg_current_wal_insert_location(PG_FUNCTION_ARGS)
* This function is mostly for debugging purposes.
*/
Datum
-pg_current_wal_flush_location(PG_FUNCTION_ARGS)
+pg_current_wal_flush_lsn(PG_FUNCTION_ARGS)
{
XLogRecPtr current_recptr;
@@ -415,7 +415,7 @@ pg_current_wal_flush_location(PG_FUNCTION_ARGS)
* and synced to disk by walreceiver.
*/
Datum
-pg_last_wal_receive_location(PG_FUNCTION_ARGS)
+pg_last_wal_receive_lsn(PG_FUNCTION_ARGS)
{
XLogRecPtr recptr;
@@ -434,7 +434,7 @@ pg_last_wal_receive_location(PG_FUNCTION_ARGS)
* connections during recovery.
*/
Datum
-pg_last_wal_replay_location(PG_FUNCTION_ARGS)
+pg_last_wal_replay_lsn(PG_FUNCTION_ARGS)
{
XLogRecPtr recptr;
@@ -621,7 +621,7 @@ pg_is_in_recovery(PG_FUNCTION_ARGS)
* Compute the difference in bytes between two WAL locations.
*/
Datum
-pg_wal_location_diff(PG_FUNCTION_ARGS)
+pg_wal_lsn_diff(PG_FUNCTION_ARGS)
{
Datum result;
diff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql
index 421d51d..3040990 100644
--- a/src/backend/catalog/system_views.sql
+++ b/src/backend/catalog/system_views.sql
@@ -724,10 +724,10 @@ CREATE VIEW pg_stat_replication AS
S.backend_start,
S.backend_xmin,
W.state,
- W.sent_location,
- W.write_location,
- W.flush_location,
- W.replay_location,
+ W.sent_lsn,
+ W.write_lsn,
+ W.flush_lsn,
+ W.replay_lsn,
W.write_lag,
W.flush_lag,
W.replay_lag,
@@ -1033,7 +1033,7 @@ CREATE OR REPLACE FUNCTION
CREATE OR REPLACE FUNCTION pg_logical_slot_get_changes(
IN slot_name name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
- OUT location pg_lsn, OUT xid xid, OUT data text)
+ OUT lsn pg_lsn, OUT xid xid, OUT data text)
RETURNS SETOF RECORD
LANGUAGE INTERNAL
VOLATILE ROWS 1000 COST 1000
@@ -1041,7 +1041,7 @@ AS 'pg_logical_slot_get_changes';
CREATE OR REPLACE FUNCTION pg_logical_slot_peek_changes(
IN slot_name name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
- OUT location pg_lsn, OUT xid xid, OUT data text)
+ OUT lsn pg_lsn, OUT xid xid, OUT data text)
RETURNS SETOF RECORD
LANGUAGE INTERNAL
VOLATILE ROWS 1000 COST 1000
@@ -1049,7 +1049,7 @@ AS 'pg_logical_slot_peek_changes';
CREATE OR REPLACE FUNCTION pg_logical_slot_get_binary_changes(
IN slot_name name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
- OUT location pg_lsn, OUT xid xid, OUT data bytea)
+ OUT lsn pg_lsn, OUT xid xid, OUT data bytea)
RETURNS SETOF RECORD
LANGUAGE INTERNAL
VOLATILE ROWS 1000 COST 1000
@@ -1057,7 +1057,7 @@ AS 'pg_logical_slot_get_binary_changes';
CREATE OR REPLACE FUNCTION pg_logical_slot_peek_binary_changes(
IN slot_name name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
- OUT location pg_lsn, OUT xid xid, OUT data bytea)
+ OUT lsn pg_lsn, OUT xid xid, OUT data bytea)
RETURNS SETOF RECORD
LANGUAGE INTERNAL
VOLATILE ROWS 1000 COST 1000
@@ -1066,7 +1066,7 @@ AS 'pg_logical_slot_peek_binary_changes';
CREATE OR REPLACE FUNCTION pg_create_physical_replication_slot(
IN slot_name name, IN immediately_reserve boolean DEFAULT false,
IN temporary boolean DEFAULT false,
- OUT slot_name name, OUT wal_position pg_lsn)
+ OUT slot_name name, OUT lsn pg_lsn)
RETURNS RECORD
LANGUAGE INTERNAL
STRICT VOLATILE
@@ -1075,7 +1075,7 @@ AS 'pg_create_physical_replication_slot';
CREATE OR REPLACE FUNCTION pg_create_logical_replication_slot(
IN slot_name name, IN plugin name,
IN temporary boolean DEFAULT false,
- OUT slot_name text, OUT wal_position pg_lsn)
+ OUT slot_name text, OUT lsn pg_lsn)
RETURNS RECORD
LANGUAGE INTERNAL
STRICT VOLATILE
diff --git a/src/backend/utils/misc/pg_controldata.c b/src/backend/utils/misc/pg_controldata.c
index d845411..56ba301 100644
--- a/src/backend/utils/misc/pg_controldata.c
+++ b/src/backend/utils/misc/pg_controldata.c
@@ -91,11 +91,11 @@ pg_control_checkpoint(PG_FUNCTION_ARGS)
* function's pg_proc entry!
*/
tupdesc = CreateTemplateTupleDesc(19, false);
- TupleDescInitEntry(tupdesc, (AttrNumber) 1, "checkpoint_location",
+ TupleDescInitEntry(tupdesc, (AttrNumber) 1, "checkpoint_lsn",
LSNOID, -1, 0);
- TupleDescInitEntry(tupdesc, (AttrNumber) 2, "prior_location",
+ TupleDescInitEntry(tupdesc, (AttrNumber) 2, "prior_lsn",
LSNOID, -1, 0);
- TupleDescInitEntry(tupdesc, (AttrNumber) 3, "redo_location",
+ TupleDescInitEntry(tupdesc, (AttrNumber) 3, "redo_lsn",
LSNOID, -1, 0);
TupleDescInitEntry(tupdesc, (AttrNumber) 4, "redo_wal_file",
TEXTOID, -1, 0);
@@ -225,13 +225,13 @@ pg_control_recovery(PG_FUNCTION_ARGS)
* function's pg_proc entry!
*/
tupdesc = CreateTemplateTupleDesc(5, false);
- TupleDescInitEntry(tupdesc, (AttrNumber) 1, "min_recovery_end_location",
+ TupleDescInitEntry(tupdesc, (AttrNumber) 1, "min_recovery_end_lsn",
LSNOID, -1, 0);
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "min_recovery_end_timeline",
INT4OID, -1, 0);
- TupleDescInitEntry(tupdesc, (AttrNumber) 3, "backup_start_location",
+ TupleDescInitEntry(tupdesc, (AttrNumber) 3, "backup_start_lsn",
LSNOID, -1, 0);
- TupleDescInitEntry(tupdesc, (AttrNumber) 4, "backup_end_location",
+ TupleDescInitEntry(tupdesc, (AttrNumber) 4, "backup_end_lsn",
LSNOID, -1, 0);
TupleDescInitEntry(tupdesc, (AttrNumber) 5, "end_of_backup_record_required",
BOOLOID, -1, 0);
diff --git a/src/bin/pg_basebackup/t/030_pg_recvlogical.pl b/src/bin/pg_basebackup/t/030_pg_recvlogical.pl
index 3e66f70..c036f4b 100644
--- a/src/bin/pg_basebackup/t/030_pg_recvlogical.pl
+++ b/src/bin/pg_basebackup/t/030_pg_recvlogical.pl
@@ -39,7 +39,7 @@ isnt($slot->{'restart_lsn'}, '', 'restart lsn is defined for new slot');
$node->psql('postgres', 'CREATE TABLE test_table(x integer)');
$node->psql('postgres', 'INSERT INTO test_table(x) SELECT y FROM generate_series(1, 10) a(y);');
-my $nextlsn = $node->safe_psql('postgres', 'SELECT pg_current_wal_insert_location()');
+my $nextlsn = $node->safe_psql('postgres', 'SELECT pg_current_wal_insert_lsn()');
chomp($nextlsn);
$node->command_ok(['pg_recvlogical', '-S', 'test', '-d', $node->connstr('postgres'), '--start', '--endpos', "$nextlsn", '--no-loop', '-f', '-'],
diff --git a/src/bin/pg_rewind/RewindTest.pm b/src/bin/pg_rewind/RewindTest.pm
index c67212f..39a559e 100644
--- a/src/bin/pg_rewind/RewindTest.pm
+++ b/src/bin/pg_rewind/RewindTest.pm
@@ -156,7 +156,7 @@ sub promote_standby
# Wait for the standby to receive and write all WAL.
my $wal_received_query =
-"SELECT pg_current_wal_location() = write_location FROM pg_stat_replication WHERE application_name = 'rewind_standby';";
+"SELECT pg_current_wal_lsn() = write_lsn FROM pg_stat_replication WHERE application_name = 'rewind_standby';";
$node_master->poll_query_until('postgres', $wal_received_query)
or die "Timed out while waiting for standby to receive and write WAL";
diff --git a/src/bin/pg_rewind/libpq_fetch.c b/src/bin/pg_rewind/libpq_fetch.c
index eb74d2f..c25367f 100644
--- a/src/bin/pg_rewind/libpq_fetch.c
+++ b/src/bin/pg_rewind/libpq_fetch.c
@@ -120,7 +120,7 @@ run_simple_query(const char *sql)
}
/*
- * Calls pg_current_wal_insert_location() function
+ * Calls pg_current_wal_insert_lsn() function
*/
XLogRecPtr
libpqGetCurrentXlogInsertLocation(void)
@@ -130,7 +130,7 @@ libpqGetCurrentXlogInsertLocation(void)
uint32 lo;
char *val;
- val = run_simple_query("SELECT pg_current_wal_insert_location()");
+ val = run_simple_query("SELECT pg_current_wal_insert_lsn()");
if (sscanf(val, "%X/%X", &hi, &lo) != 2)
pg_fatal("unrecognized result \"%s\" for current WAL insert location\n", val);
diff --git a/src/include/catalog/pg_proc.h b/src/include/catalog/pg_proc.h
index 82562ad..77d8ed5 100644
--- a/src/include/catalog/pg_proc.h
+++ b/src/include/catalog/pg_proc.h
@@ -2830,7 +2830,7 @@ DATA(insert OID = 2022 ( pg_stat_get_activity PGNSP PGUID 12 1 100 0 0 f f f
DESCR("statistics: information about currently active backends");
DATA(insert OID = 3318 ( pg_stat_get_progress_info PGNSP PGUID 12 1 100 0 0 f f f f t t s r 1 0 2249 "25" "{25,23,26,26,20,20,20,20,20,20,20,20,20,20}" "{i,o,o,o,o,o,o,o,o,o,o,o,o,o}" "{cmdtype,pid,datid,relid,param1,param2,param3,param4,param5,param6,param7,param8,param9,param10}" _null_ _null_ pg_stat_get_progress_info _null_ _null_ _null_ ));
DESCR("statistics: information about progress of backends running maintenance command");
-DATA(insert OID = 3099 ( pg_stat_get_wal_senders PGNSP PGUID 12 1 10 0 0 f f f f f t s r 0 0 2249 "" "{23,25,3220,3220,3220,3220,1186,1186,1186,23,25}" "{o,o,o,o,o,o,o,o,o,o,o}" "{pid,state,sent_location,write_location,flush_location,replay_location,write_lag,flush_lag,replay_lag,sync_priority,sync_state}" _null_ _null_ pg_stat_get_wal_senders _null_ _null_ _null_ ));
+DATA(insert OID = 3099 ( pg_stat_get_wal_senders PGNSP PGUID 12 1 10 0 0 f f f f f t s r 0 0 2249 "" "{23,25,3220,3220,3220,3220,1186,1186,1186,23,25}" "{o,o,o,o,o,o,o,o,o,o,o}" "{pid,state,sent_lsn,write_lsn,flush_lsn,replay_lsn,write_lag,flush_lag,replay_lag,sync_priority,sync_state}" _null_ _null_ pg_stat_get_wal_senders _null_ _null_ _null_ ));
DESCR("statistics: information about currently active replication");
DATA(insert OID = 3317 ( pg_stat_get_wal_receiver PGNSP PGUID 12 1 0 0 0 f f f f f f s r 0 0 2249 "" "{23,25,3220,23,3220,23,1184,1184,3220,1184,25,25}" "{o,o,o,o,o,o,o,o,o,o,o,o}" "{pid,status,receive_start_lsn,receive_start_tli,received_lsn,received_tli,last_msg_send_time,last_msg_receipt_time,latest_end_lsn,latest_end_time,slot_name,conninfo}" _null_ _null_ pg_stat_get_wal_receiver _null_ _null_ _null_ ));
DESCR("statistics: information about WAL receiver");
@@ -3215,18 +3215,18 @@ DATA(insert OID = 2848 ( pg_switch_wal PGNSP PGUID 12 1 0 0 0 f f f f t f v s
DESCR("switch to new wal file");
DATA(insert OID = 3098 ( pg_create_restore_point PGNSP PGUID 12 1 0 0 0 f f f f t f v s 1 0 3220 "25" _null_ _null_ _null_ _null_ _null_ pg_create_restore_point _null_ _null_ _null_ ));
DESCR("create a named restore point");
-DATA(insert OID = 2849 ( pg_current_wal_location PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 3220 "" _null_ _null_ _null_ _null_ _null_ pg_current_wal_location _null_ _null_ _null_ ));
+DATA(insert OID = 2849 ( pg_current_wal_lsn PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 3220 "" _null_ _null_ _null_ _null_ _null_ pg_current_wal_lsn _null_ _null_ _null_ ));
DESCR("current wal write location");
-DATA(insert OID = 2852 ( pg_current_wal_insert_location PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 3220 "" _null_ _null_ _null_ _null_ _null_ pg_current_wal_insert_location _null_ _null_ _null_ ));
+DATA(insert OID = 2852 ( pg_current_wal_insert_lsn PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 3220 "" _null_ _null_ _null_ _null_ _null_ pg_current_wal_insert_lsn _null_ _null_ _null_ ));
DESCR("current wal insert location");
-DATA(insert OID = 3330 ( pg_current_wal_flush_location PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 3220 "" _null_ _null_ _null_ _null_ _null_ pg_current_wal_flush_location _null_ _null_ _null_ ));
+DATA(insert OID = 3330 ( pg_current_wal_flush_lsn PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 3220 "" _null_ _null_ _null_ _null_ _null_ pg_current_wal_flush_lsn _null_ _null_ _null_ ));
DESCR("current wal flush location");
-DATA(insert OID = 2850 ( pg_walfile_name_offset PGNSP PGUID 12 1 0 0 0 f f f f t f i s 1 0 2249 "3220" "{3220,25,23}" "{i,o,o}" "{wal_location,file_name,file_offset}" _null_ _null_ pg_walfile_name_offset _null_ _null_ _null_ ));
+DATA(insert OID = 2850 ( pg_walfile_name_offset PGNSP PGUID 12 1 0 0 0 f f f f t f i s 1 0 2249 "3220" "{3220,25,23}" "{i,o,o}" "{lsn,file_name,file_offset}" _null_ _null_ pg_walfile_name_offset _null_ _null_ _null_ ));
DESCR("wal filename and byte offset, given a wal location");
DATA(insert OID = 2851 ( pg_walfile_name PGNSP PGUID 12 1 0 0 0 f f f f t f i s 1 0 25 "3220" _null_ _null_ _null_ _null_ _null_ pg_walfile_name _null_ _null_ _null_ ));
DESCR("wal filename, given a wal location");
-DATA(insert OID = 3165 ( pg_wal_location_diff PGNSP PGUID 12 1 0 0 0 f f f f t f i s 2 0 1700 "3220 3220" _null_ _null_ _null_ _null_ _null_ pg_wal_location_diff _null_ _null_ _null_ ));
+DATA(insert OID = 3165 ( pg_wal_lsn_diff PGNSP PGUID 12 1 0 0 0 f f f f t f i s 2 0 1700 "3220 3220" _null_ _null_ _null_ _null_ _null_ pg_wal_lsn_diff _null_ _null_ _null_ ));
DESCR("difference in bytes, given two wal locations");
DATA(insert OID = 3809 ( pg_export_snapshot PGNSP PGUID 12 1 0 0 0 f f f f t f v u 0 0 25 "" _null_ _null_ _null_ _null_ _null_ pg_export_snapshot _null_ _null_ _null_ ));
@@ -3235,9 +3235,9 @@ DESCR("export a snapshot");
DATA(insert OID = 3810 ( pg_is_in_recovery PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 16 "" _null_ _null_ _null_ _null_ _null_ pg_is_in_recovery _null_ _null_ _null_ ));
DESCR("true if server is in recovery");
-DATA(insert OID = 3820 ( pg_last_wal_receive_location PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 3220 "" _null_ _null_ _null_ _null_ _null_ pg_last_wal_receive_location _null_ _null_ _null_ ));
+DATA(insert OID = 3820 ( pg_last_wal_receive_lsn PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 3220 "" _null_ _null_ _null_ _null_ _null_ pg_last_wal_receive_lsn _null_ _null_ _null_ ));
DESCR("current wal flush location");
-DATA(insert OID = 3821 ( pg_last_wal_replay_location PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 3220 "" _null_ _null_ _null_ _null_ _null_ pg_last_wal_replay_location _null_ _null_ _null_ ));
+DATA(insert OID = 3821 ( pg_last_wal_replay_lsn PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 3220 "" _null_ _null_ _null_ _null_ _null_ pg_last_wal_replay_lsn _null_ _null_ _null_ ));
DESCR("last wal replay location");
DATA(insert OID = 3830 ( pg_last_xact_replay_timestamp PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 1184 "" _null_ _null_ _null_ _null_ _null_ pg_last_xact_replay_timestamp _null_ _null_ _null_ ));
DESCR("timestamp of last replay xact");
@@ -5285,21 +5285,21 @@ DATA(insert OID = 5016 ( spg_box_quad_leaf_consistent PGNSP PGUID 12 1 0 0 0 f
DESCR("SP-GiST support for quad tree over box");
/* replication slots */
-DATA(insert OID = 3779 ( pg_create_physical_replication_slot PGNSP PGUID 12 1 0 0 0 f f f f t f v u 3 0 2249 "19 16 16" "{19,16,16,19,3220}" "{i,i,i,o,o}" "{slot_name,immediately_reserve,temporary,slot_name,wal_position}" _null_ _null_ pg_create_physical_replication_slot _null_ _null_ _null_ ));
+DATA(insert OID = 3779 ( pg_create_physical_replication_slot PGNSP PGUID 12 1 0 0 0 f f f f t f v u 3 0 2249 "19 16 16" "{19,16,16,19,3220}" "{i,i,i,o,o}" "{slot_name,immediately_reserve,temporary,slot_name,lsn}" _null_ _null_ pg_create_physical_replication_slot _null_ _null_ _null_ ));
DESCR("create a physical replication slot");
DATA(insert OID = 3780 ( pg_drop_replication_slot PGNSP PGUID 12 1 0 0 0 f f f f t f v u 1 0 2278 "19" _null_ _null_ _null_ _null_ _null_ pg_drop_replication_slot _null_ _null_ _null_ ));
DESCR("drop a replication slot");
DATA(insert OID = 3781 ( pg_get_replication_slots PGNSP PGUID 12 1 10 0 0 f f f f f t s s 0 0 2249 "" "{19,19,25,26,16,16,23,28,28,3220,3220}" "{o,o,o,o,o,o,o,o,o,o,o}" "{slot_name,plugin,slot_type,datoid,temporary,active,active_pid,xmin,catalog_xmin,restart_lsn,confirmed_flush_lsn}" _null_ _null_ pg_get_replication_slots _null_ _null_ _null_ ));
DESCR("information about replication slots currently in use");
-DATA(insert OID = 3786 ( pg_create_logical_replication_slot PGNSP PGUID 12 1 0 0 0 f f f f t f v u 3 0 2249 "19 19 16" "{19,19,16,25,3220}" "{i,i,i,o,o}" "{slot_name,plugin,temporary,slot_name,wal_position}" _null_ _null_ pg_create_logical_replication_slot _null_ _null_ _null_ ));
+DATA(insert OID = 3786 ( pg_create_logical_replication_slot PGNSP PGUID 12 1 0 0 0 f f f f t f v u 3 0 2249 "19 19 16" "{19,19,16,25,3220}" "{i,i,i,o,o}" "{slot_name,plugin,temporary,slot_name,lsn}" _null_ _null_ pg_create_logical_replication_slot _null_ _null_ _null_ ));
DESCR("set up a logical replication slot");
-DATA(insert OID = 3782 ( pg_logical_slot_get_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v u 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,25}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ _null_ pg_logical_slot_get_changes _null_ _null_ _null_ ));
+DATA(insert OID = 3782 ( pg_logical_slot_get_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v u 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,25}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,lsn,xid,data}" _null_ _null_ pg_logical_slot_get_changes _null_ _null_ _null_ ));
DESCR("get changes from replication slot");
-DATA(insert OID = 3783 ( pg_logical_slot_get_binary_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v u 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,17}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ _null_ pg_logical_slot_get_binary_changes _null_ _null_ _null_ ));
+DATA(insert OID = 3783 ( pg_logical_slot_get_binary_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v u 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,17}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,lsn,xid,data}" _null_ _null_ pg_logical_slot_get_binary_changes _null_ _null_ _null_ ));
DESCR("get binary changes from replication slot");
-DATA(insert OID = 3784 ( pg_logical_slot_peek_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v u 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,25}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ _null_ pg_logical_slot_peek_changes _null_ _null_ _null_ ));
+DATA(insert OID = 3784 ( pg_logical_slot_peek_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v u 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,25}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,lsn,xid,data}" _null_ _null_ pg_logical_slot_peek_changes _null_ _null_ _null_ ));
DESCR("peek at changes from replication slot");
-DATA(insert OID = 3785 ( pg_logical_slot_peek_binary_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v u 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,17}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ _null_ pg_logical_slot_peek_binary_changes _null_ _null_ _null_ ));
+DATA(insert OID = 3785 ( pg_logical_slot_peek_binary_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v u 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,17}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,lsn,xid,data}" _null_ _null_ pg_logical_slot_peek_binary_changes _null_ _null_ _null_ ));
DESCR("peek at binary changes from replication slot");
DATA(insert OID = 3577 ( pg_logical_emit_message PGNSP PGUID 12 1 0 0 0 f f f f t f v u 3 0 3220 "16 25 25" _null_ _null_ _null_ _null_ _null_ pg_logical_emit_message_text _null_ _null_ _null_ ));
DESCR("emit a textual logical decoding message");
@@ -5447,10 +5447,10 @@ DESCR("pg_config binary as a function");
DATA(insert OID = 3441 ( pg_control_system PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 2249 "" "{23,23,20,1184}" "{o,o,o,o}" "{pg_control_version,catalog_version_no,system_identifier,pg_control_last_modified}" _null_ _null_ pg_control_system _null_ _null_ _null_ ));
DESCR("pg_controldata general state information as a function");
-DATA(insert OID = 3442 ( pg_control_checkpoint PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 2249 "" "{3220,3220,3220,25,23,23,16,25,26,28,28,28,26,28,28,26,28,28,1184}" "{o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o}" "{checkpoint_location,prior_location,redo_location,redo_wal_file,timeline_id,prev_timeline_id,full_page_writes,next_xid,next_oid,next_multixact_id,next_multi_offset,oldest_xid,oldest_xid_dbid,oldest_active_xid,oldest_multi_xid,oldest_multi_dbid,oldest_commit_ts_xid,newest_commit_ts_xid,checkpoint_time}" _null_ _null_ pg_control_checkpoint _null_ _null_ _null_ ));
+DATA(insert OID = 3442 ( pg_control_checkpoint PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 2249 "" "{3220,3220,3220,25,23,23,16,25,26,28,28,28,26,28,28,26,28,28,1184}" "{o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o}" "{checkpoint_lsn,prior_lsn,redo_lsn,redo_wal_file,timeline_id,prev_timeline_id,full_page_writes,next_xid,next_oid,next_multixact_id,next_multi_offset,oldest_xid,oldest_xid_dbid,oldest_active_xid,oldest_multi_xid,oldest_multi_dbid,oldest_commit_ts_xid,newest_commit_ts_xid,checkpoint_time}" _null_ _null_ pg_control_checkpoint _null_ _null_ _null_ ));
DESCR("pg_controldata checkpoint state information as a function");
-DATA(insert OID = 3443 ( pg_control_recovery PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 2249 "" "{3220,23,3220,3220,16}" "{o,o,o,o,o}" "{min_recovery_end_location,min_recovery_end_timeline,backup_start_location,backup_end_location,end_of_backup_record_required}" _null_ _null_ pg_control_recovery _null_ _null_ _null_ ));
+DATA(insert OID = 3443 ( pg_control_recovery PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 2249 "" "{3220,23,3220,3220,16}" "{o,o,o,o,o}" "{min_recovery_end_lsn,min_recovery_end_timeline,backup_start_lsn,backup_end_lsn,end_of_backup_record_required}" _null_ _null_ pg_control_recovery _null_ _null_ _null_ ));
DESCR("pg_controldata recovery state information as a function");
DATA(insert OID = 3444 ( pg_control_init PGNSP PGUID 12 1 0 0 0 f f f f t f v s 0 0 2249 "" "{23,23,23,23,23,23,23,23,23,16,16,23}" "{o,o,o,o,o,o,o,o,o,o,o,o}" "{max_data_alignment,database_block_size,blocks_per_segment,wal_block_size,bytes_per_wal_segment,max_identifier_length,max_index_columns,max_toast_chunk_size,large_object_chunk_size,float4_pass_by_value,float8_pass_by_value,data_page_checksum_version}" _null_ _null_ pg_control_init _null_ _null_ _null_ ));
diff --git a/src/test/modules/commit_ts/t/002_standby.pl b/src/test/modules/commit_ts/t/002_standby.pl
index 203b75d..e7221e9 100644
--- a/src/test/modules/commit_ts/t/002_standby.pl
+++ b/src/test/modules/commit_ts/t/002_standby.pl
@@ -31,9 +31,9 @@ my $master_ts = $master->safe_psql('postgres',
qq{SELECT ts.* FROM pg_class, pg_xact_commit_timestamp(xmin) AS ts WHERE relname = 't10'}
);
my $master_lsn =
- $master->safe_psql('postgres', 'select pg_current_wal_location()');
+ $master->safe_psql('postgres', 'select pg_current_wal_lsn()');
$standby->poll_query_until('postgres',
- qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_location()})
+ qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_lsn()})
or die "slave never caught up";
my $standby_ts = $standby->safe_psql('postgres',
@@ -45,9 +45,9 @@ $master->append_conf('postgresql.conf', 'track_commit_timestamp = off');
$master->restart;
$master->safe_psql('postgres', 'checkpoint');
$master_lsn =
- $master->safe_psql('postgres', 'select pg_current_wal_location()');
+ $master->safe_psql('postgres', 'select pg_current_wal_lsn()');
$standby->poll_query_until('postgres',
- qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_location()})
+ qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_lsn()})
or die "slave never caught up";
$standby->safe_psql('postgres', 'checkpoint');
diff --git a/src/test/modules/commit_ts/t/003_standby_2.pl b/src/test/modules/commit_ts/t/003_standby_2.pl
index d7898b8..2fd5611 100644
--- a/src/test/modules/commit_ts/t/003_standby_2.pl
+++ b/src/test/modules/commit_ts/t/003_standby_2.pl
@@ -30,9 +30,9 @@ $master->append_conf('postgresql.conf', 'track_commit_timestamp = off');
$master->restart;
$master->safe_psql('postgres', 'checkpoint');
my $master_lsn =
- $master->safe_psql('postgres', 'select pg_current_wal_location()');
+ $master->safe_psql('postgres', 'select pg_current_wal_lsn()');
$standby->poll_query_until('postgres',
- qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_location()})
+ qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_lsn()})
or die "slave never caught up";
$standby->safe_psql('postgres', 'checkpoint');
diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm
index 51cbec8..e3f1089 100644
--- a/src/test/perl/PostgresNode.pm
+++ b/src/test/perl/PostgresNode.pm
@@ -1362,11 +1362,11 @@ mode must be specified.
sub lsn
{
my ($self, $mode) = @_;
- my %modes = ('insert' => 'pg_current_wal_insert_location()',
- 'flush' => 'pg_current_wal_flush_location()',
- 'write' => 'pg_current_wal_location()',
- 'receive' => 'pg_last_wal_receive_location()',
- 'replay' => 'pg_last_wal_replay_location()');
+ my %modes = ('insert' => 'pg_current_wal_insert_lsn()',
+ 'flush' => 'pg_current_wal_flush_lsn()',
+ 'write' => 'pg_current_wal_lsn()',
+ 'receive' => 'pg_last_wal_receive_lsn()',
+ 'replay' => 'pg_last_wal_replay_lsn()');
$mode = '<undef>' if !defined($mode);
die "unknown mode for 'lsn': '$mode', valid modes are " . join(', ', keys %modes)
@@ -1391,8 +1391,8 @@ sub lsn
Wait for the node with application_name standby_name (usually from node->name)
until its replication position in pg_stat_replication equals or passes the
upstream's WAL insert point at the time this function is called. By default
-the replay_location is waited for, but 'mode' may be specified to wait for any
-of sent|write|flush|replay.
+the replay_lsn is waited for, but 'mode' may be specified to wait for any of
+sent|write|flush|replay.
If there is no active replication connection from this peer, waits until
poll_query_until timeout.
@@ -1417,8 +1417,8 @@ sub wait_for_catchup
$standby_name = $standby_name->name;
}
die 'target_lsn must be specified' unless defined($target_lsn);
- print "Waiting for replication conn " . $standby_name . "'s " . $mode . "_location to pass " . $target_lsn . " on " . $self->name . "\n";
- my $query = qq[SELECT '$target_lsn' <= ${mode}_location FROM pg_catalog.pg_stat_replication WHERE application_name = '$standby_name';];
+ print "Waiting for replication conn " . $standby_name . "'s " . $mode . "_lsn to pass " . $target_lsn . " on " . $self->name . "\n";
+ my $query = qq[SELECT '$target_lsn' <= ${mode}_lsn FROM pg_catalog.pg_stat_replication WHERE application_name = '$standby_name';];
$self->poll_query_until('postgres', $query)
or die "timed out waiting for catchup, current position is " . ($self->safe_psql('postgres', $query) || '(unknown)');
print "done\n";
diff --git a/src/test/recovery/t/002_archiving.pl b/src/test/recovery/t/002_archiving.pl
index e4a643d..42a9afb 100644
--- a/src/test/recovery/t/002_archiving.pl
+++ b/src/test/recovery/t/002_archiving.pl
@@ -31,7 +31,7 @@ $node_standby->start;
$node_master->safe_psql('postgres',
"CREATE TABLE tab_int AS SELECT generate_series(1,1000) AS a");
my $current_lsn =
- $node_master->safe_psql('postgres', "SELECT pg_current_wal_location();");
+ $node_master->safe_psql('postgres', "SELECT pg_current_wal_lsn();");
# Force archiving of WAL file to make it present on master
$node_master->safe_psql('postgres', "SELECT pg_switch_wal()");
@@ -42,7 +42,7 @@ $node_master->safe_psql('postgres',
# Wait until necessary replay has been done on standby
my $caughtup_query =
- "SELECT '$current_lsn'::pg_lsn <= pg_last_wal_replay_location()";
+ "SELECT '$current_lsn'::pg_lsn <= pg_last_wal_replay_lsn()";
$node_standby->poll_query_until('postgres', $caughtup_query)
or die "Timed out while waiting for standby to catch up";
diff --git a/src/test/recovery/t/003_recovery_targets.pl b/src/test/recovery/t/003_recovery_targets.pl
index 203a464..66025cd 100644
--- a/src/test/recovery/t/003_recovery_targets.pl
+++ b/src/test/recovery/t/003_recovery_targets.pl
@@ -30,7 +30,7 @@ sub test_recovery_standby
# Wait until standby has replayed enough data
my $caughtup_query =
- "SELECT '$until_lsn'::pg_lsn <= pg_last_wal_replay_location()";
+ "SELECT '$until_lsn'::pg_lsn <= pg_last_wal_replay_lsn()";
$node_standby->poll_query_until('postgres', $caughtup_query)
or die "Timed out while waiting for standby to catch up";
@@ -55,7 +55,7 @@ $node_master->start;
$node_master->safe_psql('postgres',
"CREATE TABLE tab_int AS SELECT generate_series(1,1000) AS a");
my $lsn1 =
- $node_master->safe_psql('postgres', "SELECT pg_current_wal_location();");
+ $node_master->safe_psql('postgres', "SELECT pg_current_wal_lsn();");
# Take backup from which all operations will be run
$node_master->backup('my_backup');
@@ -65,14 +65,14 @@ $node_master->backup('my_backup');
$node_master->safe_psql('postgres',
"INSERT INTO tab_int VALUES (generate_series(1001,2000))");
my $ret = $node_master->safe_psql('postgres',
- "SELECT pg_current_wal_location(), txid_current();");
+ "SELECT pg_current_wal_lsn(), txid_current();");
my ($lsn2, $recovery_txid) = split /\|/, $ret;
# More data, with recovery target timestamp
$node_master->safe_psql('postgres',
"INSERT INTO tab_int VALUES (generate_series(2001,3000))");
$ret = $node_master->safe_psql('postgres',
- "SELECT pg_current_wal_location(), now();");
+ "SELECT pg_current_wal_lsn(), now();");
my ($lsn3, $recovery_time) = split /\|/, $ret;
# Even more data, this time with a recovery target name
@@ -80,16 +80,16 @@ $node_master->safe_psql('postgres',
"INSERT INTO tab_int VALUES (generate_series(3001,4000))");
my $recovery_name = "my_target";
my $lsn4 =
- $node_master->safe_psql('postgres', "SELECT pg_current_wal_location();");
+ $node_master->safe_psql('postgres', "SELECT pg_current_wal_lsn();");
$node_master->safe_psql('postgres',
"SELECT pg_create_restore_point('$recovery_name');");
# And now for a recovery target LSN
$node_master->safe_psql('postgres',
"INSERT INTO tab_int VALUES (generate_series(4001,5000))");
-my $recovery_lsn = $node_master->safe_psql('postgres', "SELECT pg_current_wal_location()");
+my $recovery_lsn = $node_master->safe_psql('postgres', "SELECT pg_current_wal_lsn()");
my $lsn5 =
- $node_master->safe_psql('postgres', "SELECT pg_current_wal_location();");
+ $node_master->safe_psql('postgres', "SELECT pg_current_wal_lsn();");
$node_master->safe_psql('postgres',
"INSERT INTO tab_int VALUES (generate_series(5001,6000))");
diff --git a/src/test/recovery/t/005_replay_delay.pl b/src/test/recovery/t/005_replay_delay.pl
index cd9e8f5..4185f58 100644
--- a/src/test/recovery/t/005_replay_delay.pl
+++ b/src/test/recovery/t/005_replay_delay.pl
@@ -42,7 +42,7 @@ $node_master->safe_psql('postgres',
# Now wait for replay to complete on standby. We're done waiting when the
# slave has replayed up to the previously saved master LSN.
my $until_lsn =
- $node_master->safe_psql('postgres', "SELECT pg_current_wal_location()");
+ $node_master->safe_psql('postgres', "SELECT pg_current_wal_lsn()");
my $remaining = 90;
while ($remaining-- > 0)
@@ -50,7 +50,7 @@ while ($remaining-- > 0)
# Done waiting?
my $replay_status = $node_standby->safe_psql('postgres',
- "SELECT (pg_last_wal_replay_location() - '$until_lsn'::pg_lsn) >= 0"
+ "SELECT (pg_last_wal_replay_lsn() - '$until_lsn'::pg_lsn) >= 0"
);
last if $replay_status eq 't';
diff --git a/src/test/recovery/t/006_logical_decoding.pl b/src/test/recovery/t/006_logical_decoding.pl
index bf9b50a..31b1218 100644
--- a/src/test/recovery/t/006_logical_decoding.pl
+++ b/src/test/recovery/t/006_logical_decoding.pl
@@ -53,7 +53,7 @@ COMMIT};
my $stdout_sql = $node_master->safe_psql('postgres', qq[SELECT data FROM pg_logical_slot_peek_changes('test_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');]);
is($stdout_sql, $expected, 'got expected output from SQL decoding session');
-my $endpos = $node_master->safe_psql('postgres', "SELECT location FROM pg_logical_slot_peek_changes('test_slot', NULL, NULL) ORDER BY location DESC LIMIT 1;");
+my $endpos = $node_master->safe_psql('postgres', "SELECT lsn FROM pg_logical_slot_peek_changes('test_slot', NULL, NULL) ORDER BY lsn DESC LIMIT 1;");
print "waiting to replay $endpos\n";
my $stdout_recv = $node_master->pg_recvlogical_upto('postgres', 'test_slot', $endpos, 10, 'include-xids' => '0', 'skip-empty-xacts' => '1');
@@ -66,7 +66,7 @@ is($stdout_recv, '', 'pg_recvlogical acknowledged changes, nothing pending on sl
$node_master->safe_psql('postgres', 'CREATE DATABASE otherdb');
-is($node_master->psql('otherdb', "SELECT location FROM pg_logical_slot_peek_changes('test_slot', NULL, NULL) ORDER BY location DESC LIMIT 1;"), 3,
+is($node_master->psql('otherdb', "SELECT lsn FROM pg_logical_slot_peek_changes('test_slot', NULL, NULL) ORDER BY lsn DESC LIMIT 1;"), 3,
'replaying logical slot from another database fails');
$node_master->safe_psql('otherdb', qq[SELECT pg_create_logical_replication_slot('otherdb_slot', 'test_decoding');]);
diff --git a/src/test/recovery/t/008_fsm_truncation.pl b/src/test/recovery/t/008_fsm_truncation.pl
index 8aa8a4f..055cac3 100644
--- a/src/test/recovery/t/008_fsm_truncation.pl
+++ b/src/test/recovery/t/008_fsm_truncation.pl
@@ -68,11 +68,11 @@ vacuum verbose testtab;
$node_master->psql('postgres', 'checkpoint');
my $until_lsn =
- $node_master->safe_psql('postgres', "SELECT pg_current_wal_location();");
+ $node_master->safe_psql('postgres', "SELECT pg_current_wal_lsn();");
# Wait long enough for standby to receive and apply all WAL
my $caughtup_query =
- "SELECT '$until_lsn'::pg_lsn <= pg_last_wal_replay_location()";
+ "SELECT '$until_lsn'::pg_lsn <= pg_last_wal_replay_lsn()";
$node_standby->poll_query_until('postgres', $caughtup_query)
or die "Timed out while waiting for standby to catch up";
diff --git a/src/test/recovery/t/010_logical_decoding_timelines.pl b/src/test/recovery/t/010_logical_decoding_timelines.pl
index cdddb4d..e168cbc 100644
--- a/src/test/recovery/t/010_logical_decoding_timelines.pl
+++ b/src/test/recovery/t/010_logical_decoding_timelines.pl
@@ -169,7 +169,7 @@ is($stderr, '', 'replay from slot before_basebackup produces no stderr');
# pg_recvlogical we should get complete results. First, find out the commit lsn
# of the last transaction. There's no max(pg_lsn), so:
-my $endpos = $node_replica->safe_psql('postgres', "SELECT location FROM pg_logical_slot_peek_changes('before_basebackup', NULL, NULL) ORDER BY location DESC LIMIT 1;");
+my $endpos = $node_replica->safe_psql('postgres', "SELECT lsn FROM pg_logical_slot_peek_changes('before_basebackup', NULL, NULL) ORDER BY lsn DESC LIMIT 1;");
# now use the walsender protocol to peek the slot changes and make sure we see
# the same results.
diff --git a/src/test/regress/expected/rules.out b/src/test/regress/expected/rules.out
index 0165471..fd74bde 100644
--- a/src/test/regress/expected/rules.out
+++ b/src/test/regress/expected/rules.out
@@ -1851,17 +1851,17 @@ pg_stat_replication| SELECT s.pid,
s.backend_start,
s.backend_xmin,
w.state,
- w.sent_location,
- w.write_location,
- w.flush_location,
- w.replay_location,
+ w.sent_lsn,
+ w.write_lsn,
+ w.flush_lsn,
+ w.replay_lsn,
w.write_lag,
w.flush_lag,
w.replay_lag,
w.sync_priority,
w.sync_state
FROM ((pg_stat_get_activity(NULL::integer) s(datid, pid, usesysid, application_name, state, query, wait_event_type, wait_event, xact_start, query_start, backend_start, state_change, client_addr, client_hostname, client_port, backend_xid, backend_xmin, backend_type, ssl, sslversion, sslcipher, sslbits, sslcompression, sslclientdn)
- JOIN pg_stat_get_wal_senders() w(pid, state, sent_location, write_location, flush_location, replay_location, write_lag, flush_lag, replay_lag, sync_priority, sync_state) ON ((s.pid = w.pid)))
+ JOIN pg_stat_get_wal_senders() w(pid, state, sent_lsn, write_lsn, flush_lsn, replay_lsn, write_lag, flush_lag, replay_lag, sync_priority, sync_state) ON ((s.pid = w.pid)))
LEFT JOIN pg_authid u ON ((s.usesysid = u.oid)));
pg_stat_ssl| SELECT s.pid,
s.ssl,
diff --git a/src/test/subscription/t/001_rep_changes.pl b/src/test/subscription/t/001_rep_changes.pl
index d1817f5..a7a9e0e 100644
--- a/src/test/subscription/t/001_rep_changes.pl
+++ b/src/test/subscription/t/001_rep_changes.pl
@@ -52,7 +52,7 @@ $node_subscriber->safe_psql('postgres',
# Wait for subscriber to finish initialization
my $caughtup_query =
-"SELECT pg_current_wal_location() <= replay_location FROM pg_stat_replication WHERE application_name = '$appname';";
+"SELECT pg_current_wal_lsn() <= replay_lsn FROM pg_stat_replication WHERE application_name = '$appname';";
$node_publisher->poll_query_until('postgres', $caughtup_query)
or die "Timed out while waiting for subscriber to catch up";
diff --git a/src/test/subscription/t/002_types.pl b/src/test/subscription/t/002_types.pl
index ad15e85..16e8b47 100644
--- a/src/test/subscription/t/002_types.pl
+++ b/src/test/subscription/t/002_types.pl
@@ -107,7 +107,7 @@ $node_subscriber->safe_psql('postgres',
# Wait for subscriber to finish initialization
my $caughtup_query =
-"SELECT pg_current_wal_location() <= replay_location FROM pg_stat_replication WHERE application_name = '$appname';";
+"SELECT pg_current_wal_lsn() <= replay_lsn FROM pg_stat_replication WHERE application_name = '$appname';";
$node_publisher->poll_query_until('postgres', $caughtup_query)
or die "Timed out while waiting for subscriber to catch up";
diff --git a/src/test/subscription/t/003_constraints.pl b/src/test/subscription/t/003_constraints.pl
index 11b8254..074fdb1 100644
--- a/src/test/subscription/t/003_constraints.pl
+++ b/src/test/subscription/t/003_constraints.pl
@@ -38,7 +38,7 @@ $node_subscriber->safe_psql('postgres',
# Wait for subscriber to finish initialization
my $caughtup_query =
-"SELECT pg_current_wal_location() <= replay_location FROM pg_stat_replication WHERE application_name = '$appname';";
+"SELECT pg_current_wal_lsn() <= replay_lsn FROM pg_stat_replication WHERE application_name = '$appname';";
$node_publisher->poll_query_until('postgres', $caughtup_query)
or die "Timed out while waiting for subscriber to catch up";
diff --git a/src/test/subscription/t/004_sync.pl b/src/test/subscription/t/004_sync.pl
index fa0bf7f..ceeb7a3 100644
--- a/src/test/subscription/t/004_sync.pl
+++ b/src/test/subscription/t/004_sync.pl
@@ -37,7 +37,7 @@ $node_subscriber->safe_psql('postgres',
# Wait for subscriber to finish initialization
my $caughtup_query =
-"SELECT pg_current_wal_location() <= replay_location FROM pg_stat_replication WHERE application_name = '$appname';";
+"SELECT pg_current_wal_lsn() <= replay_lsn FROM pg_stat_replication WHERE application_name = '$appname';";
$node_publisher->poll_query_until('postgres', $caughtup_query)
or die "Timed out while waiting for subscriber to catch up";
diff --git a/src/test/subscription/t/005_encoding.pl b/src/test/subscription/t/005_encoding.pl
index 42a4eee..7a62e05 100644
--- a/src/test/subscription/t/005_encoding.pl
+++ b/src/test/subscription/t/005_encoding.pl
@@ -10,7 +10,7 @@ sub wait_for_caught_up
my ($node, $appname) = @_;
$node->poll_query_until('postgres',
- "SELECT pg_current_wal_location() <= replay_location FROM pg_stat_replication WHERE application_name = '$appname';")
+ "SELECT pg_current_wal_lsn() <= replay_lsn FROM pg_stat_replication WHERE application_name = '$appname';")
or die "Timed out while waiting for subscriber to catch up";
}
On 2 May 2017 at 00:10, David Rowley <david.rowley@2ndquadrant.com> wrote:
On 20 April 2017 at 07:29, Euler Taveira <euler@timbira.com.br> wrote:
2017-04-19 1:32 GMT-03:00 Michael Paquier <michael.paquier@gmail.com>:
I vote for "location" -> "lsn". I would expect complains about the
current inconsistency at some point, and the function names have been
already changed for this release..OK, so I've created a draft patch which does this.
I ended up adding this to the open items list. I feel it's best to be
on there so that we don't forget about this.
If we decide not to do it then we can just remove it from the list,
but it would be a shame to release the beta having forgotten to make
this change.
Do any of the committers who voted for this change feel inclined to
pick this patch up?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 05, 2017 at 03:36:39AM +1200, David Rowley wrote:
On 2 May 2017 at 00:10, David Rowley <david.rowley@2ndquadrant.com> wrote:
On 20 April 2017 at 07:29, Euler Taveira <euler@timbira.com.br> wrote:
2017-04-19 1:32 GMT-03:00 Michael Paquier <michael.paquier@gmail.com>:
I vote for "location" -> "lsn". I would expect complains about the
current inconsistency at some point, and the function names have been
already changed for this release..OK, so I've created a draft patch which does this.
I ended up adding this to the open items list. I feel it's best to be
on there so that we don't forget about this.If we decide not to do it then we can just remove it from the list,
but it would be a shame to release the beta having forgotten to make
this change.Do any of the committers who voted for this change feel inclined to
pick this patch up?
I'll echo that question. This open item lacks a clear owner. One might argue
that 806091c caused it by doing the backward-compatibility breaks that
inspired this patch, but that's a link too tenuous to create ownership.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
On Fri, May 05, 2017 at 03:36:39AM +1200, David Rowley wrote:
Do any of the committers who voted for this change feel inclined to
pick this patch up?
I'll echo that question. This open item lacks a clear owner. One might argue
that 806091c caused it by doing the backward-compatibility breaks that
inspired this patch, but that's a link too tenuous to create ownership.
If no one else takes this, I will pick it up --- but I don't anticipate
having any time for it until after Monday's back-branch release wraps.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, May 6, 2017 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Noah Misch <noah@leadboat.com> writes:
On Fri, May 05, 2017 at 03:36:39AM +1200, David Rowley wrote:
Do any of the committers who voted for this change feel inclined to
pick this patch up?I'll echo that question. This open item lacks a clear owner. One might
argue
that 806091c caused it by doing the backward-compatibility breaks that
inspired this patch, but that's a link too tenuous to create ownership.If no one else takes this, I will pick it up --- but I don't anticipate
having any time for it until after Monday's back-branch release wraps.
[In case forgotten] pg_controdata and pg_waldump interfaces should also be
considered for this standardization.
Following are pg_controldata interfaces that might require change:
Latest checkpoint location:
Prior checkpoint location:
Latest checkpoint's REDO location:
Minimum recovery ending location:
Backup start location:
Backup end location:
The pg_waldump help options(and probably documentation) would also require
change:
-e, --end=RECPTR stop reading at log position RECPTR
-s, --start=RECPTR start reading at log position RECPTR
Regards,
Neha
On 5/1/17 08:10, David Rowley wrote:
On 20 April 2017 at 07:29, Euler Taveira <euler@timbira.com.br> wrote:
2017-04-19 1:32 GMT-03:00 Michael Paquier <michael.paquier@gmail.com>:
I vote for "location" -> "lsn". I would expect complains about the
current inconsistency at some point, and the function names have been
already changed for this release..OK, so I've created a draft patch which does this.
After reading this patch, I see that
a) The scope of the compatibility break is expanded significantly beyond
what was already affected by the xlog->wal renaming.
b) Generally, things read less nicely and look more complicated.
So I still think we'd be better off leaving things the way they are.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 5/1/17 08:10, David Rowley wrote:
OK, so I've created a draft patch which does this.
After reading this patch, I see that
a) The scope of the compatibility break is expanded significantly beyond
what was already affected by the xlog->wal renaming.
b) Generally, things read less nicely and look more complicated.
So I still think we'd be better off leaving things the way they are.
What I find in a bit of looking around is that
1. There are no functions named *lsn* except the support functions
for the pg_lsn type.
2. There are half a dozen or so functions named *location* (the
ones hit in this patch). All of them existed in 9.6, but with
names involving "xlog"; they're already renamed to involve "wal".
3. We have these system columns named *lsn*:
regression=# select attrelid::regclass, attname, atttypid::regtype from pg_attribute where attname like '%lsn%' and attrelid<16384;
attrelid | attname | atttypid
------------------------------+---------------------+----------
pg_stat_wal_receiver | receive_start_lsn | pg_lsn
pg_stat_wal_receiver | received_lsn | pg_lsn
pg_stat_wal_receiver | latest_end_lsn | pg_lsn
pg_replication_slots | restart_lsn | pg_lsn
pg_replication_slots | confirmed_flush_lsn | pg_lsn
pg_replication_origin_status | remote_lsn | pg_lsn
pg_replication_origin_status | local_lsn | pg_lsn
pg_subscription_rel | srsublsn | pg_lsn
pg_stat_subscription | received_lsn | pg_lsn
pg_stat_subscription | latest_end_lsn | pg_lsn
(10 rows)
The first seven of those existed in 9.6.
4. We have these system columns named *location*:
regression=# select attrelid::regclass, attname, atttypid::regtype from pg_attribute where attname like '%location%' and attrelid<16384;
attrelid | attname | atttypid
---------------------+-----------------+----------
pg_stat_replication | sent_location | pg_lsn
pg_stat_replication | write_location | pg_lsn
pg_stat_replication | flush_location | pg_lsn
pg_stat_replication | replay_location | pg_lsn
(4 rows)
All of those existed in 9.6. The patch proposes to rename them to *lsn.
So it seems like we do not have such a big problem with function names:
the relevant functions all use "location" in their names, and we could
just keep doing that. The problem that we've got is inconsistency in
table/view column names. However, there is no way to fix it without
adding a new dollop of compatibility break on top of what we've done
already.
For completeness, I think the available alternatives are:
#1: Leave these names as they stand.
#2: Rename all these functions and columns to "lsn", as in this patch.
#3: Rename the functions but not the columns.
#4: Leave the function names alone, standardize on "lsn" in column names
(hence, touching pg_stat_replication only).
#5: Standardize on "location" not "lsn" (hence, leaving the function
names alone, and touching pg_stat_wal_receiver, pg_replication_slots,
and pg_replication_origin_status, as well as the new-in-v10-anyway
pg_subscription_rel and pg_stat_subscription).
#3 has the advantage of not breaking anything we didn't break already,
but it isn't accomplishing very much in terms of improving consistency.
With #4, we have a rule that function names use "location" while column
names use "lsn", which is a bit odd but not terrible.
I think #5 would best serve Peter's point about readability, because
I agree that "lsn" isn't doing us any favors in that direction.
So this boils down to whether we are willing to touch any of these
column names in order to improve consistency. I think it might be
worth doing, but there's no doubt that we're adding more compatibility
pain if we do anything but #1 or #3.
regards, tom lane
PS: There are some other changes in David's patch, such as
s/position/location/ in some text, that I think we should do in any
case. But the first decision has to be about the view column names.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom, all,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 5/1/17 08:10, David Rowley wrote:
OK, so I've created a draft patch which does this.
After reading this patch, I see that
a) The scope of the compatibility break is expanded significantly beyond
what was already affected by the xlog->wal renaming.
Changing one additional view doesn't strike me as a significantly
expanded set.
b) Generally, things read less nicely and look more complicated.
I disagree.
So I still think we'd be better off leaving things the way they are.
What I find in a bit of looking around is that
1. There are no functions named *lsn* except the support functions
for the pg_lsn type.
Even so, that doesn't strike me as having been particularly intentional
or because it was "better" to use something else, especially given the
column naming.
2. There are half a dozen or so functions named *location* (the
ones hit in this patch). All of them existed in 9.6, but with
names involving "xlog"; they're already renamed to involve "wal".
Right, so changing location -> lsn for those doesn't expand the
compatibility issue really.
3. We have these system columns named *lsn*:
regression=# select attrelid::regclass, attname, atttypid::regtype from pg_attribute where attname like '%lsn%' and attrelid<16384;
attrelid | attname | atttypid
------------------------------+---------------------+----------
pg_stat_wal_receiver | receive_start_lsn | pg_lsn
pg_stat_wal_receiver | received_lsn | pg_lsn
pg_stat_wal_receiver | latest_end_lsn | pg_lsn
pg_replication_slots | restart_lsn | pg_lsn
pg_replication_slots | confirmed_flush_lsn | pg_lsn
pg_replication_origin_status | remote_lsn | pg_lsn
pg_replication_origin_status | local_lsn | pg_lsn
pg_subscription_rel | srsublsn | pg_lsn
pg_stat_subscription | received_lsn | pg_lsn
pg_stat_subscription | latest_end_lsn | pg_lsn
(10 rows)The first seven of those existed in 9.6.
4. We have these system columns named *location*:
regression=# select attrelid::regclass, attname, atttypid::regtype from pg_attribute where attname like '%location%' and attrelid<16384;
attrelid | attname | atttypid
---------------------+-----------------+----------
pg_stat_replication | sent_location | pg_lsn
pg_stat_replication | write_location | pg_lsn
pg_stat_replication | flush_location | pg_lsn
pg_stat_replication | replay_location | pg_lsn
(4 rows)All of those existed in 9.6. The patch proposes to rename them to *lsn.
Right, four column names in one view- the one view which is different
from all of the other views that exist.
So it seems like we do not have such a big problem with function names:
the relevant functions all use "location" in their names, and we could
just keep doing that. The problem that we've got is inconsistency in
table/view column names. However, there is no way to fix it without
adding a new dollop of compatibility break on top of what we've done
already.For completeness, I think the available alternatives are:
#1: Leave these names as they stand.
-1
#2: Rename all these functions and columns to "lsn", as in this patch.
+1
#3: Rename the functions but not the columns.
-1
#4: Leave the function names alone, standardize on "lsn" in column names
(hence, touching pg_stat_replication only).
-1
#5: Standardize on "location" not "lsn" (hence, leaving the function
names alone, and touching pg_stat_wal_receiver, pg_replication_slots,
and pg_replication_origin_status, as well as the new-in-v10-anyway
pg_subscription_rel and pg_stat_subscription).
Ugh, that seems even worse, and expands the compatibility breakage, -5.
#3 has the advantage of not breaking anything we didn't break already,
but it isn't accomplishing very much in terms of improving consistency.
Agreed.
With #4, we have a rule that function names use "location" while column
names use "lsn", which is a bit odd but not terrible.
Given that we're changing the function names already, I really don't see
why this makes any sense. Perhaps it's just me, but 'location' is much
more of a vague term than 'lsn' and if we're talking about an 'lsn' then
that's what we should be using.
I think #5 would best serve Peter's point about readability, because
I agree that "lsn" isn't doing us any favors in that direction.
I disagree that 'lsn' is worse than 'location'- at least for my part,
it's much more precise and clear about what we're talking about.
"location" could be where a file exists on the disk, where in the world
we are, where we are in the heap, where we are when stepping through an
index, etc. With the work on adding progress information for things
like VACUUM, and I think there was something about tracking progress of
copying a table for logical replication, it certainly seems likely that
we may have cause to think about the point we are in the heap or in an
index.
So this boils down to whether we are willing to touch any of these
column names in order to improve consistency. I think it might be
worth doing, but there's no doubt that we're adding more compatibility
pain if we do anything but #1 or #3.
#2 strikes me as the best option, though that's probably not much of a
surprise to anyone whose been following my comments on this thread.
PS: There are some other changes in David's patch, such as
s/position/location/ in some text, that I think we should do in any
case. But the first decision has to be about the view column names.
Agreed.
Thanks!
Stephen
On 5/9/17 10:00 AM, Stephen Frost wrote:
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
#2: Rename all these functions and columns to "lsn", as in this patch.
+1
<...>
#2 strikes me as the best option, though that's probably not much of a
surprise to anyone whose been following my comments on this thread.
+1. If anything this analysis make me more convinced it is the right
thing to do.
If I read this correctly, we won't change the names of any functions
that we haven't *already* changed the names of, and only one view would
be changed to bring it into line with the rest.
--
-David
david@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Steele <david@pgmasters.net> writes:
If I read this correctly, we won't change the names of any functions
that we haven't *already* changed the names of, and only one view would
be changed to bring it into line with the rest.
I have now looked through the patch more carefully, and noted some changes
I forgot to account for in my previous summary: it also renames some
function arguments and output columns, which previously were variously
"location", "wal_position", etc. I'd missed that for functions that don't
have a formal view in front of them. This affects
pg_control_checkpoint
pg_control_recovery
pg_create_logical_replication_slot
pg_create_physical_replication_slot
pg_logical_slot_get_binary_changes
pg_logical_slot_get_changes
pg_logical_slot_peek_binary_changes
pg_logical_slot_peek_changes
So that's an additional source of possible compatibility breaks.
It doesn't seem like enough to change anybody's vote on the issue,
but I mention it for completeness.
In terms of the alternatives I listed previously, it seems like
nobody liked alternatives #3, #4, or #5, leaving us with #1 (do
nothing) or #2 (apply this patch). By my count, Peter is the
only one in favor of doing nothing, and is outvoted. I'll push
the patch later today if I don't hear additional comments.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 10, 2017 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Steele <david@pgmasters.net> writes:
If I read this correctly, we won't change the names of any functions
that we haven't *already* changed the names of, and only one view would
be changed to bring it into line with the rest.I have now looked through the patch more carefully, and noted some changes
I forgot to account for in my previous summary: it also renames some
function arguments and output columns, which previously were variously
"location", "wal_position", etc. I'd missed that for functions that don't
have a formal view in front of them. This affectspg_control_checkpoint
pg_control_recovery
pg_create_logical_replication_slot
pg_create_physical_replication_slot
pg_logical_slot_get_binary_changes
pg_logical_slot_get_changes
pg_logical_slot_peek_binary_changes
pg_logical_slot_peek_changesSo that's an additional source of possible compatibility breaks.
It doesn't seem like enough to change anybody's vote on the issue,
but I mention it for completeness.In terms of the alternatives I listed previously, it seems like
nobody liked alternatives #3, #4, or #5, leaving us with #1 (do
nothing) or #2 (apply this patch). By my count, Peter is the
only one in favor of doing nothing, and is outvoted. I'll push
the patch later today if I don't hear additional comments.
For the record, I also voted for doing nothing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, May 10, 2017 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
In terms of the alternatives I listed previously, it seems like
nobody liked alternatives #3, #4, or #5, leaving us with #1 (do
nothing) or #2 (apply this patch). By my count, Peter is the
only one in favor of doing nothing, and is outvoted. I'll push
the patch later today if I don't hear additional comments.
For the record, I also voted for doing nothing.
Hm, well, anybody else want to vote?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/10/2017 12:22 PM, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, May 10, 2017 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
In terms of the alternatives I listed previously, it seems like
nobody liked alternatives #3, #4, or #5, leaving us with #1 (do
nothing) or #2 (apply this patch). By my count, Peter is the
only one in favor of doing nothing, and is outvoted. I'll push
the patch later today if I don't hear additional comments.For the record, I also voted for doing nothing.
Hm, well, anybody else want to vote?
+1 for #2
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
On 10/05/17 21:22, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, May 10, 2017 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
In terms of the alternatives I listed previously, it seems like
nobody liked alternatives #3, #4, or #5, leaving us with #1 (do
nothing) or #2 (apply this patch). By my count, Peter is the
only one in favor of doing nothing, and is outvoted. I'll push
the patch later today if I don't hear additional comments.For the record, I also voted for doing nothing.
Hm, well, anybody else want to vote?
I am for standardizing (although I don't have preference of location vs
lsn).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 10, 2017 at 01:09:36PM -0700, Joe Conway wrote:
On 05/10/2017 12:22 PM, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, May 10, 2017 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
In terms of the alternatives I listed previously, it seems like
nobody liked alternatives #3, #4, or #5, leaving us with #1 (do
nothing) or #2 (apply this patch). By my count, Peter is the
only one in favor of doing nothing, and is outvoted. I'll push
the patch later today if I don't hear additional comments.For the record, I also voted for doing nothing.
Hm, well, anybody else want to vote?
+1 for #2
Same, +1 for #2 (apply this patch)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 11, 2017 at 9:15 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, May 10, 2017 at 01:09:36PM -0700, Joe Conway wrote:
On 05/10/2017 12:22 PM, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, May 10, 2017 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
In terms of the alternatives I listed previously, it seems like
nobody liked alternatives #3, #4, or #5, leaving us with #1 (do
nothing) or #2 (apply this patch). By my count, Peter is the
only one in favor of doing nothing, and is outvoted. I'll push
the patch later today if I don't hear additional comments.For the record, I also voted for doing nothing.
Hm, well, anybody else want to vote?
+1 for #2
Same, +1 for #2 (apply this patch)
#1, do nothing.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
On Thu, May 11, 2017 at 9:15 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, May 10, 2017 at 01:09:36PM -0700, Joe Conway wrote:
On 05/10/2017 12:22 PM, Tom Lane wrote:
Hm, well, anybody else want to vote?
+1 for #2
Same, +1 for #2 (apply this patch)
#1, do nothing.
OK, by my count we have
For patch:
Joe Conway
Stephen Frost
Kyotaro Horiguchi (*)
Petr Jelinek (*)
Tom Lane
Bruce Momjian
David Rowley
David Steele
Euler Taveira
For doing nothing:
Peter Eisentraut
Robert Haas
Michael Paquier
I think Kyotaro-san and Petr would have preferred standardizing
on "location" over "lsn", but they were definitely not for doing
nothing. With or without their votes, it's pretty clear that the
ayes have it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Neha Khatri <nehakhatri5@gmail.com> writes:
[In case forgotten] pg_controdata and pg_waldump interfaces should also be
considered for this standardization.
Following are pg_controldata interfaces that might require change:
Latest checkpoint location:
Prior checkpoint location:
Latest checkpoint's REDO location:
Minimum recovery ending location:
Backup start location:
Backup end location:
My inclination is to leave these messages alone. They're not really
inconsistent with anything. Where we seem to be ending up is that
"lsn" will be used in things like function and column names, but
documentation will continue to spell out phrases like "WAL location".
There is another open thread about converting said phrases to be
more consistent --- a lot of them currently say "transaction log
location", which is not a very good choice because it invites
confusion with pg_xact nee pg_clog. But I think that's mostly
just documentation changes, and in any case it's better done as
a separate patch.
The pg_waldump help options(and probably documentation) would also require
change:
-e, --end=RECPTR stop reading at log position RECPTR
-s, --start=RECPTR start reading at log position RECPTR
Yeah, probably s/log position/WAL location/ would be better here.
But again that seems like material for a separate patch. The
current patch does do s/position/location/ in a few places, but
it's not trying to apply that policy everywhere.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 12, 2017 at 12:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Neha Khatri <nehakhatri5@gmail.com> writes:
[In case forgotten] pg_controdata and pg_waldump interfaces should also
be
considered for this standardization.
Following are pg_controldata interfaces that might require change:
Latest checkpoint location:
Prior checkpoint location:
Latest checkpoint's REDO location:
Minimum recovery ending location:
Backup start location:
Backup end location:My inclination is to leave these messages alone. They're not really
inconsistent with anything. Where we seem to be ending up is that
"lsn" will be used in things like function and column names, but
documentation will continue to spell out phrases like "WAL location".There is another open thread about converting said phrases to be
more consistent --- a lot of them currently say "transaction log
location", which is not a very good choice because it invites
confusion with pg_xact nee pg_clog. But I think that's mostly
just documentation changes, and in any case it's better done as
a separate patch.
Are you indicating that the above phrases do not require change because
those are consistent with other references. Or the other thread [1]/messages/by-id/89ba433e-8990-0aad-238f-55e1d7280ece@2ndquadrant.com
(renaming 'transaction log') should take care of it.
Regards,
Neha
[1]: /messages/by-id/89ba433e-8990-0aad-238f-55e1d7280ece@2ndquadrant.com
/messages/by-id/89ba433e-8990-0aad-238f-55e1d7280ece@2ndquadrant.com
Neha Khatri <nehakhatri5@gmail.com> writes:
On Fri, May 12, 2017 at 12:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Neha Khatri <nehakhatri5@gmail.com> writes:
Following are pg_controldata interfaces that might require change:
Latest checkpoint location:
Prior checkpoint location:
Latest checkpoint's REDO location:
Minimum recovery ending location:
Backup start location:
Backup end location:
My inclination is to leave these messages alone. They're not really
inconsistent with anything. Where we seem to be ending up is that
"lsn" will be used in things like function and column names, but
documentation will continue to spell out phrases like "WAL location".
Are you indicating that the above phrases do not require change because
those are consistent with other references. Or the other thread [1]
(renaming 'transaction log') should take care of it.
Personally I'm happy to leave those particular messages as they are.
Yes, a case could be made for changing them to say "LSN", and a different
case could be made for changing them to say "WAL location", but I don't
think either of those are real improvements. Also, this'd be propagating
the compatibility problem into yet a new place, because there are surely
user-written scripts out there that grep the output for exactly these
spellings.
It's a judgment call though, and others might have different opinions.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers