Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Bruce Momjian]

On Fri, Feb  3, 2017 at 05:21:28AM -0500, Stephen Frost wrote:
> > Also googling for pg_wal, I'm finding food for thought like this
> > IBM technote:
> > http://www-01.ibm.com/support/docview.wss?uid=isg3T1015637
> > which recommends to 
> > "Remove all files under /var/lib/pgsql/9.0/data/pg_wal/"
> > and also calls that directory the "write-ahead log directory"
> > which is quite confusing because apparently it's the destination of
> > their archive command.
> 
> It's certainly unfortunate that people have thought that they can create
> arbitrary directories under the PG data directory.  That's never going
> to be safe, witness that we've created new directories under PGDATA in
> the last few releases and I don't see any reason why that would change
> moving forward.  Perhaps we should check for the existance of such a
> directory during pg_upgrade and throw an error, and we should go back
> and do the same for other directories which have been added over
> releases, but I'm not sure I can see an argument for doing much more
> than that.

Actually, pg_upgrade already checks for some odd directories stored
inside of PGDATA:

WARNING:  new data directory should not be inside the
old data directory, e.g. %s\n", old_cluster_pgdata);

WARNING:  user-defined tablespace locations should
not be inside the data directory, e.g. %s\n", old_tablespace_dir);

-- 
  Bruce Momjian  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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Josh Berkus (j...@berkus.org) wrote:
> On 02/09/2017 05:19 PM, Michael Paquier wrote:
> > On Fri, Feb 10, 2017 at 10:16 AM, Stephen Frost  wrote:
> >>> As someone mentioned, forcing a user to install an extension makes
> >>> the deprecation visible. Another option would be to have the backend
> >>> spit out a WARNING the first time you access anything that's
> >>> deprecated. Both of those are pertinent reminders to people that
> >>> they need to change their tools.
> >>
> >> Ugh.  Please, no.  Hacking up the backend to recognize that a given
> >> query is referring to a deprecated view and then throwing a warning on
> >> it is just plain ugly.
> >>
> >> Let's go one step further, and throw an ERROR if someone tries to query
> >> these views instead.
> > 
> > FWIW, I am of the opinion to just nuke them as the "soft of"
> > deprecation period has been very long. Applications should have
> > switched to pg_authid and pg_roles long ago already.
> 
> We will definitely break a lot of client code by removing these -- I
> know that, deprecated or not, a lot of infrequently-updated
> driver/orm/GUI code still refers to pg_shadow/pg_user.

Any that we're aware of, I'd suggest we reach out to the maintainers of
and let them know.

> I think Postgres 10 is the right time to break that code (I mean, we
> have to do it someday, and we're already telling people about breakage
> in 10), but be aware that there will be shouting and carrying on.

Agreed.

> -1 on a warning.  Very little code today which references the deprecated
> code is interactive, so who's going to see the warning?

Indeed, I was thinking of this also.  The warnings would just end up in
the server logs, amongst tons of often not-terribly-interesting
information that far too many users ignore already, and those that don't
probably actually read the release notes.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Josh Berkus]

On 02/09/2017 05:19 PM, Michael Paquier wrote:
> On Fri, Feb 10, 2017 at 10:16 AM, Stephen Frost  wrote:
>>> As someone mentioned, forcing a user to install an extension makes
>>> the deprecation visible. Another option would be to have the backend
>>> spit out a WARNING the first time you access anything that's
>>> deprecated. Both of those are pertinent reminders to people that
>>> they need to change their tools.
>>
>> Ugh.  Please, no.  Hacking up the backend to recognize that a given
>> query is referring to a deprecated view and then throwing a warning on
>> it is just plain ugly.
>>
>> Let's go one step further, and throw an ERROR if someone tries to query
>> these views instead.
> 
> FWIW, I am of the opinion to just nuke them as the "soft of"
> deprecation period has been very long. Applications should have
> switched to pg_authid and pg_roles long ago already.
> 

We will definitely break a lot of client code by removing these -- I
know that, deprecated or not, a lot of infrequently-updated
driver/orm/GUI code still refers to pg_shadow/pg_user.

I think Postgres 10 is the right time to break that code (I mean, we
have to do it someday, and we're already telling people about breakage
in 10), but be aware that there will be shouting and carrying on.

-1 on a warning.  Very little code today which references the deprecated
code is interactive, so who's going to see the warning?

-- 
Josh Berkus
Containers & Databases Oh My!


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-02-09 20:02:54 -0500, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:
> > > I'd love to nuke pg_shadow and all the other
> > > not-really-maintained backwards-compat things from when roles were
> > > added too.
> > 
> > Not sure if it's worth the work to rip out and such, but I'm mildly
> > supportive of this one too.  Depends a bit on what all the other things
> > are ;)
> 
> Reviewing 7762619e95272974f90a38d8d85aafbe0e94add5 where roles were
> added, I find:
> 
> pg_user   - use pg_roles instead, which actually includes all of the role
> attributes, unlike pg_user

Hm, I presume this is the most used one.


> pg_group  - use pg_auth_members instead, which includes the info about
> the admin option and the grantor

then this.

> pg_shadow - use pg_authid instead, which, again, actually includes all
> of the role attributes, unlike pg_shadow.

That's probably fine.


I'm fine with dropping now, alternatively we could, and that seems like
it'd institute a good practice, name them to be removed in 10+1 in the
10 release notes. "Upcoming removal of deprecated features" or such. And
schedule stuff for that regularly.  Like e.g. dropping psql support for
< 9.0 (randomly chosen version), pg_dump support for very old versions,
etc, ...
While not everyone will be saved by that (by virtue of not reading /
reacting) it helps those that actually read the notes.  Obviously
there'd still some incompatibilities that do not go through that
mechanism.


> I don't think we should remove things like CREATE USER, that's a
> perfectly reasonable and maintained interface, unlike the above views,
> which missed out on things like the 'createrole' role attribute.

Yea, that'd be a bad plan.


Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Michael Paquier]

On Fri, Feb 10, 2017 at 10:16 AM, Stephen Frost  wrote:
>> As someone mentioned, forcing a user to install an extension makes
>> the deprecation visible. Another option would be to have the backend
>> spit out a WARNING the first time you access anything that's
>> deprecated. Both of those are pertinent reminders to people that
>> they need to change their tools.
>
> Ugh.  Please, no.  Hacking up the backend to recognize that a given
> query is referring to a deprecated view and then throwing a warning on
> it is just plain ugly.
>
> Let's go one step further, and throw an ERROR if someone tries to query
> these views instead.

FWIW, I am of the opinion to just nuke them as the "soft of"
deprecation period has been very long. Applications should have
switched to pg_authid and pg_roles long ago already.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

Jim,

* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 2/9/17 6:37 PM, Andres Freund wrote:
> >>I'd love to nuke pg_shadow and all the other
> >>not-really-maintained backwards-compat things from when roles were
> >>added too.
> >Not sure if it's worth the work to rip out and such, but I'm mildly
> >supportive of this one too.  Depends a bit on what all the other things
> >are ;)
> 
> The problem with pg_shadow is unless you specifically looked at it
> in the docs after 8.1, you had no idea it was deprecated. I don't
> really think of it as deprecated.

It's not even maintained properly, I hardly see how it couldn't be
anything but deprecated, and the docs certainly are the right place, if
anywhere, to say that something is deprecated.

> As someone mentioned, forcing a user to install an extension makes
> the deprecation visible. Another option would be to have the backend
> spit out a WARNING the first time you access anything that's
> deprecated. Both of those are pertinent reminders to people that
> they need to change their tools.

Ugh.  Please, no.  Hacking up the backend to recognize that a given
query is referring to a deprecated view and then throwing a warning on
it is just plain ugly.

Let's go one step further, and throw an ERROR if someone tries to query
these views instead.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Andres Freund (and...@anarazel.de) wrote:
> On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:
> > I'd love to nuke pg_shadow and all the other
> > not-really-maintained backwards-compat things from when roles were
> > added too.
> 
> Not sure if it's worth the work to rip out and such, but I'm mildly
> supportive of this one too.  Depends a bit on what all the other things
> are ;)

Reviewing 7762619e95272974f90a38d8d85aafbe0e94add5 where roles were
added, I find:

pg_user   - use pg_roles instead, which actually includes all of the role
attributes, unlike pg_user

pg_shadow - use pg_authid instead, which, again, actually includes all
of the role attributes, unlike pg_shadow.

pg_group  - use pg_auth_members instead, which includes the info about
the admin option and the grantor

I don't think we should remove things like CREATE USER, that's a
perfectly reasonable and maintained interface, unlike the above views,
which missed out on things like the 'createrole' role attribute.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Jim Nasby]

On 2/9/17 6:37 PM, Andres Freund wrote:

Anybody who still wants tsearch2 can go get it from an old version, or
somebody can maintain a fork on github.

Works for me.

+1


+1


I'd love to nuke pg_shadow and all the other
not-really-maintained backwards-compat things from when roles were
added too.

Not sure if it's worth the work to rip out and such, but I'm mildly
supportive of this one too.  Depends a bit on what all the other things
are ;)


The problem with pg_shadow is unless you specifically looked at it in 
the docs after 8.1, you had no idea it was deprecated. I don't really 
think of it as deprecated.


As someone mentioned, forcing a user to install an extension makes the 
deprecation visible. Another option would be to have the backend spit 
out a WARNING the first time you access anything that's deprecated. Both 
of those are pertinent reminders to people that they need to change 
their tools.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane  wrote:
> > > Also, our experience with contrib/tsearch2 suggests that the extension
> > > shouldn't be part of contrib, because we have zero track record of getting
> > > rid of stuff in contrib, no matter how dead it is.
> > 
> > Let's nuke tsearch2 to remove this adverse precedent, and then add the
> > new thing.
> > 
> > Anybody who still wants tsearch2 can go get it from an old version, or
> > somebody can maintain a fork on github.
> 
> Works for me.

+1


> I'd love to nuke pg_shadow and all the other
> not-really-maintained backwards-compat things from when roles were
> added too.

Not sure if it's worth the work to rip out and such, but I'm mildly
supportive of this one too.  Depends a bit on what all the other things
are ;)

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane  wrote:
> > Also, our experience with contrib/tsearch2 suggests that the extension
> > shouldn't be part of contrib, because we have zero track record of getting
> > rid of stuff in contrib, no matter how dead it is.
> 
> Let's nuke tsearch2 to remove this adverse precedent, and then add the
> new thing.
> 
> Anybody who still wants tsearch2 can go get it from an old version, or
> somebody can maintain a fork on github.

Works for me.  I'd love to nuke pg_shadow and all the other
not-really-maintained backwards-compat things from when roles were
added too.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane  wrote:
> Also, our experience with contrib/tsearch2 suggests that the extension
> shouldn't be part of contrib, because we have zero track record of getting
> rid of stuff in contrib, no matter how dead it is.

Let's nuke tsearch2 to remove this adverse precedent, and then add the
new thing.

Anybody who still wants tsearch2 can go get it from an old version, or
somebody can maintain a fork on github.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Tom Lane]

Stephen Frost  writes:
> * Josh Berkus (j...@berkus.org) wrote:
>> If we clearly mark the old function names as deprecated aliases, client
>> tools will gradually move to the new names.

> No, they won't.  They haven't.  Look at pg_shadow- it was clearly marked
> as deprecated in *8.1*.

Back in 8.1 we didn't have extensions.  Now that we do, I think the
terms of discussion are a bit different.  In particular, if we relegate
the aliases to an extension, the pain of getting/installing that extension
will provide a forcing function encouraging users to fix their code so
they don't need it anymore.

Also, our experience with contrib/tsearch2 suggests that the extension
shouldn't be part of contrib, because we have zero track record of getting
rid of stuff in contrib, no matter how dead it is.

So I'm entirely happy with somebody who feels a need for this developing
an extension that we don't ship with the core system, and maintaining it
for as long as they continue to feel the need for it.  We couldn't stop
that from happening anyway.  But let's not buy into maintaining it as
part of the core distribution.  We don't have a mechanism for getting
rid of stuff once it's in the distro.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-02-09 13:03:41 -0800, Josh Berkus wrote:
> Counter-argument: moving the directory is going to break many tools
> anyway, so why bother with function aliases?

There's not actually that many tools affected by renaming pg_xlog,
i.e. there are tools that aren't affected by the rename at all, but do
calle *xlog* functions.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Josh Berkus (j...@berkus.org) wrote:
> On 02/09/2017 12:53 PM, Stephen Frost wrote:
> > Waiting 10+ years doesn't make the pain go away when it comes to
> > removing things like that.
> 
> Sure it does.  That's two whole generations of client tools.  For
> example, at that point, pgAdmin3 won't reliably run on any supported
> platform, so it won't be a problem if we break it.

That's not true if OpenSCG has their way as they're continuing to
maintain it, from my understanding.

And, I'm sorry, but counting on projects to essentially die off to be
the point where we can drop certain bits of backwards-compatibility just
isn't a winning strategy.

> If we clearly mark the old function names as deprecated aliases, client
> tools will gradually move to the new names.

No, they won't.  They haven't.  Look at pg_shadow- it was clearly marked
as deprecated in *8.1*.

> Counter-argument: moving the directory is going to break many tools
> anyway, so why bother with function aliases?

You're going to have to explain exactly the argument you're making
there, because I don't see the point you're trying to get at with that
question.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[David Steele]

On 2/9/17 4:03 PM, Josh Berkus wrote:

> Counter-argument: moving the directory is going to break many tools
> anyway, so why bother with function aliases?

+1.

-- 
-David
da...@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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

Andres,

* Andres Freund (and...@anarazel.de) wrote:
> On 2017-02-09 15:53:47 -0500, Stephen Frost wrote:
> > * Josh Berkus (j...@berkus.org) wrote:
> > > What I'm voting against is the idea that we'll have aliases in core, but
> > > remove them in two releases.  Either that's unrealistic, or it's just
> > > prolonging the pain.
> > 
> > Waiting 10+ years doesn't make the pain go away when it comes to
> > removing things like that.
> 
> That's ridiculous. I think we can fairly argue whether backward compat
> is worth it, but claiming that migrations to something new aren't easier
> if there's a number of versions that support both the old and the new
> names/syntax/whatnot is obviously wrong.

We do provide a number of years of overlap- 5 years in fact.  I believe
that's an entirely good thing and gives our users a chance to manage
their upgrade paths from one major release to the next.

Increasing that overlap to 10 or 15 years, however, doesn't make a
hill-of-beans worth of difference, in my opinion.  Either they're
tracking the releases that we're doing and making changes and adapting
as we change things, or they aren't and won't ever unless they're forced
to, instead preferring to make us carry the burden of maintenance on the
backwards-compat pieces.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Josh Berkus]

On 02/09/2017 12:53 PM, Stephen Frost wrote:
> * Josh Berkus (j...@berkus.org) wrote:
>> On 02/09/2017 12:42 PM, Stephen Frost wrote:
>>> * Josh Berkus (j...@berkus.org) wrote:
 On 02/09/2017 11:08 AM, Tom Lane wrote:
> Agreed, let's just get it done.
>
> Although this doesn't really settle whether we ought to do 3a (with
> backwards-compatibility function aliases in core) or 3b (without 'em).
> Do people want to re-vote, understanding that those are the remaining
> choices?

 Does 3a) mean keeping the aliases more-or-less forever?

 If not, I vote for 3b.  If we're going to need to break stuff, let's
 just do it.

 If we can keep the aliases for 6-10 years, then I see no reason not to
 have them (3a).  They're not exactly likely to conflict with user-chosen
 names.
>>>
>>> When we remove pg_shadow, then I'll be willing to agree that maybe we
>>> can start having things in PG for a couple releases that are just for
>>> backwards-compatibility and will actually be removed later.
>>>
>>> History has shown that's next to impossible, however.
>>
>> That's why I said 6-10 years.  If we're doing 3a, realistically we're
>> supporting it until PostgreSQL 16, at least, and more likely 20.  I'm OK
>> with that.
> 
> Uh, to be clear, I think it's an entirely bad thing that we've had those
> views and various other cruft hang around for over 10 years.
> 
> And removing them today will probably still have people crying about how
> pgAdmin3 and other things still use them.
> 
>> What I'm voting against is the idea that we'll have aliases in core, but
>> remove them in two releases.  Either that's unrealistic, or it's just
>> prolonging the pain.
> 
> Waiting 10+ years doesn't make the pain go away when it comes to
> removing things like that.

Sure it does.  That's two whole generations of client tools.  For
example, at that point, pgAdmin3 won't reliably run on any supported
platform, so it won't be a problem if we break it.

If we clearly mark the old function names as deprecated aliases, client
tools will gradually move to the new names.

Counter-argument: moving the directory is going to break many tools
anyway, so why bother with function aliases?

-- 
Josh Berkus
Containers & Databases Oh My!


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-02-09 15:53:47 -0500, Stephen Frost wrote:
> * Josh Berkus (j...@berkus.org) wrote:
> > What I'm voting against is the idea that we'll have aliases in core, but
> > remove them in two releases.  Either that's unrealistic, or it's just
> > prolonging the pain.
> 
> Waiting 10+ years doesn't make the pain go away when it comes to
> removing things like that.

That's ridiculous. I think we can fairly argue whether backward compat
is worth it, but claiming that migrations to something new aren't easier
if there's a number of versions that support both the old and the new
names/syntax/whatnot is obviously wrong.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Josh Berkus (j...@berkus.org) wrote:
> On 02/09/2017 12:42 PM, Stephen Frost wrote:
> > * Josh Berkus (j...@berkus.org) wrote:
> >> On 02/09/2017 11:08 AM, Tom Lane wrote:
> >>> Agreed, let's just get it done.
> >>>
> >>> Although this doesn't really settle whether we ought to do 3a (with
> >>> backwards-compatibility function aliases in core) or 3b (without 'em).
> >>> Do people want to re-vote, understanding that those are the remaining
> >>> choices?
> >>
> >> Does 3a) mean keeping the aliases more-or-less forever?
> >>
> >> If not, I vote for 3b.  If we're going to need to break stuff, let's
> >> just do it.
> >>
> >> If we can keep the aliases for 6-10 years, then I see no reason not to
> >> have them (3a).  They're not exactly likely to conflict with user-chosen
> >> names.
> > 
> > When we remove pg_shadow, then I'll be willing to agree that maybe we
> > can start having things in PG for a couple releases that are just for
> > backwards-compatibility and will actually be removed later.
> > 
> > History has shown that's next to impossible, however.
> 
> That's why I said 6-10 years.  If we're doing 3a, realistically we're
> supporting it until PostgreSQL 16, at least, and more likely 20.  I'm OK
> with that.

Uh, to be clear, I think it's an entirely bad thing that we've had those
views and various other cruft hang around for over 10 years.

And removing them today will probably still have people crying about how
pgAdmin3 and other things still use them.

> What I'm voting against is the idea that we'll have aliases in core, but
> remove them in two releases.  Either that's unrealistic, or it's just
> prolonging the pain.

Waiting 10+ years doesn't make the pain go away when it comes to
removing things like that.

Let's not go there.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Josh Berkus]

On 02/09/2017 12:42 PM, Stephen Frost wrote:
> * Josh Berkus (j...@berkus.org) wrote:
>> On 02/09/2017 11:08 AM, Tom Lane wrote:
>>> Agreed, let's just get it done.
>>>
>>> Although this doesn't really settle whether we ought to do 3a (with
>>> backwards-compatibility function aliases in core) or 3b (without 'em).
>>> Do people want to re-vote, understanding that those are the remaining
>>> choices?
>>
>> Does 3a) mean keeping the aliases more-or-less forever?
>>
>> If not, I vote for 3b.  If we're going to need to break stuff, let's
>> just do it.
>>
>> If we can keep the aliases for 6-10 years, then I see no reason not to
>> have them (3a).  They're not exactly likely to conflict with user-chosen
>> names.
> 
> When we remove pg_shadow, then I'll be willing to agree that maybe we
> can start having things in PG for a couple releases that are just for
> backwards-compatibility and will actually be removed later.
> 
> History has shown that's next to impossible, however.

That's why I said 6-10 years.  If we're doing 3a, realistically we're
supporting it until PostgreSQL 16, at least, and more likely 20.  I'm OK
with that.

What I'm voting against is the idea that we'll have aliases in core, but
remove them in two releases.  Either that's unrealistic, or it's just
prolonging the pain.

-- 
Josh Berkus
Containers & Databases Oh My!


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Josh Berkus (j...@berkus.org) wrote:
> On 02/09/2017 11:08 AM, Tom Lane wrote:
> > Agreed, let's just get it done.
> > 
> > Although this doesn't really settle whether we ought to do 3a (with
> > backwards-compatibility function aliases in core) or 3b (without 'em).
> > Do people want to re-vote, understanding that those are the remaining
> > choices?
> 
> Does 3a) mean keeping the aliases more-or-less forever?
> 
> If not, I vote for 3b.  If we're going to need to break stuff, let's
> just do it.
> 
> If we can keep the aliases for 6-10 years, then I see no reason not to
> have them (3a).  They're not exactly likely to conflict with user-chosen
> names.

When we remove pg_shadow, then I'll be willing to agree that maybe we
can start having things in PG for a couple releases that are just for
backwards-compatibility and will actually be removed later.

History has shown that's next to impossible, however.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Josh Berkus]

On 02/09/2017 11:08 AM, Tom Lane wrote:
> Agreed, let's just get it done.
> 
> Although this doesn't really settle whether we ought to do 3a (with
> backwards-compatibility function aliases in core) or 3b (without 'em).
> Do people want to re-vote, understanding that those are the remaining
> choices?

Does 3a) mean keeping the aliases more-or-less forever?

If not, I vote for 3b.  If we're going to need to break stuff, let's
just do it.

If we can keep the aliases for 6-10 years, then I see no reason not to
have them (3a).  They're not exactly likely to conflict with user-chosen
names.

-- 
Josh Berkus
Containers & Databases Oh My!


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Kevin Grittner]

On Thu, Feb 9, 2017 at 1:44 PM, Tom Lane  wrote:
> Robert Haas  writes:
>> On Thu, Feb 9, 2017 at 2:08 PM, Tom Lane  wrote:
>>> Although this doesn't really settle whether we ought to do 3a (with
>>> backwards-compatibility function aliases in core) or 3b (without 'em).
>>> Do people want to re-vote, understanding that those are the remaining
>>> choices?
>
>> I prefer (3c) put them in an extension and let people that need 'em
>> install 'em, but not have them available by default.
>
> As far as the core code is concerned, 3b and 3c are the same thing.

I think so, too, if we're talking about an extension in core.

My vote is for 3b.  If someone wants to write the alias extension and
make it available outside of core, fine -- though they don't need anyone's
vote to do so.

-- 
Kevin Grittner


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Tom Lane]

Robert Haas  writes:
> On Thu, Feb 9, 2017 at 2:08 PM, Tom Lane  wrote:
>> Although this doesn't really settle whether we ought to do 3a (with
>> backwards-compatibility function aliases in core) or 3b (without 'em).
>> Do people want to re-vote, understanding that those are the remaining
>> choices?

> I prefer (3c) put them in an extension and let people that need 'em
> install 'em, but not have them available by default.

As far as the core code is concerned, 3b and 3c are the same thing.
IOW, somebody can write the extension later.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Thu, Feb 9, 2017 at 2:08 PM, Tom Lane  wrote:
> Robert Haas  writes:
>> On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander  wrote:
 Here is what I have, 6 votes clearly stated:
 1. Rename nothing: Daniel,
 2. Rename directory only: Andres
 3. Rename everything: Stephen, Vladimir, David S, Michael P (with
 aliases for functions, I could live without at this point...)
>
>> [ vote-counting ]
>
>> Therefore, I plan to go ahead and do #3.  Somebody's probably going to
>> jump in now with another opinion but I think this thread's gone on
>> long enough.
>
> Agreed, let's just get it done.
>
> Although this doesn't really settle whether we ought to do 3a (with
> backwards-compatibility function aliases in core) or 3b (without 'em).
> Do people want to re-vote, understanding that those are the remaining
> choices?

I prefer (3c) put them in an extension and let people that need 'em
install 'em, but not have them available by default.  If the only
choices are (3a) and (3b) then I guess I pick (3b), but I think an
extension doesn't cost much and will ease the migration pain for users
so I'm in favor of it.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-02-09 14:08:14 -0500, Tom Lane wrote:
> Robert Haas  writes:
> > On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander  
> > wrote:
> >>> Here is what I have, 6 votes clearly stated:
> >>> 1. Rename nothing: Daniel,
> >>> 2. Rename directory only: Andres
> >>> 3. Rename everything: Stephen, Vladimir, David S, Michael P (with
> >>> aliases for functions, I could live without at this point...)
> 
> > [ vote-counting ]
> 
> > Therefore, I plan to go ahead and do #3.  Somebody's probably going to
> > jump in now with another opinion but I think this thread's gone on
> > long enough.
> 
> Agreed, let's just get it done.
> 
> Although this doesn't really settle whether we ought to do 3a (with
> backwards-compatibility function aliases in core) or 3b (without 'em).
> Do people want to re-vote, understanding that those are the remaining
> choices?

3a)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[David G. Johnston]

On Thu, Feb 9, 2017 at 12:08 PM, Tom Lane  wrote:

> Robert Haas  writes:
> > On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander 
> wrote:
> >>> Here is what I have, 6 votes clearly stated:
> >>> 1. Rename nothing: Daniel,
> >>> 2. Rename directory only: Andres
> >>> 3. Rename everything: Stephen, Vladimir, David S, Michael P (with
> >>> aliases for functions, I could live without at this point...)
>
> > [ vote-counting ]
>
> > Therefore, I plan to go ahead and do #3.  Somebody's probably going to
> > jump in now with another opinion but I think this thread's gone on
> > long enough.
>
> Agreed, let's just get it done.
>
> Although this doesn't really settle whether we ought to do 3a (with
> backwards-compatibility function aliases in core) or 3b (without 'em).
> Do people want to re-vote, understanding that those are the remaining
> choices?
>

​I wouldn't oppose:

CREATE EXTENSION give_me_my_xlog_back;

but my prior thoughts lead me toward not including such functions in the
bootstrap catalog.

David J.

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[David Steele]

On 2/9/17 2:14 PM, David G. Johnston wrote:
> On Thu, Feb 9, 2017 at 12:08 PM, Tom Lane  >wrote:
> 
> Robert Haas mailto:robertmh...@gmail.com>>
> writes:
> > On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander  > wrote:
> >>> Here is what I have, 6 votes clearly stated:
> >>> 1. Rename nothing: Daniel,
> >>> 2. Rename directory only: Andres
> >>> 3. Rename everything: Stephen, Vladimir, David S, Michael P (with
> >>> aliases for functions, I could live without at this point...)
> 
> > [ vote-counting ]
> 
> > Therefore, I plan to go ahead and do #3.  Somebody's probably going to
> > jump in now with another opinion but I think this thread's gone on
> > long enough.
> 
> Agreed, let's just get it done.
> 
> Although this doesn't really settle whether we ought to do 3a (with
> backwards-compatibility function aliases in core) or 3b (without 'em).
> Do people want to re-vote, understanding that those are the remaining
> choices?

-1 on aliases in core (so to be clear my vote is for 3b).

> ​I wouldn't oppose:
> 
> CREATE EXTENSION give_me_my_xlog_back;
> 
> but my prior thoughts lead me toward not including such functions in the
> bootstrap catalog.

I'm not very excited about an extension, can we just provide a link to a
script in the release notes, or simply note that wrappers can be created?

-- 
-David
da...@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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Tom Lane]

Robert Haas  writes:
> On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander  wrote:
>>> Here is what I have, 6 votes clearly stated:
>>> 1. Rename nothing: Daniel,
>>> 2. Rename directory only: Andres
>>> 3. Rename everything: Stephen, Vladimir, David S, Michael P (with
>>> aliases for functions, I could live without at this point...)

> [ vote-counting ]

> Therefore, I plan to go ahead and do #3.  Somebody's probably going to
> jump in now with another opinion but I think this thread's gone on
> long enough.

Agreed, let's just get it done.

Although this doesn't really settle whether we ought to do 3a (with
backwards-compatibility function aliases in core) or 3b (without 'em).
Do people want to re-vote, understanding that those are the remaining
choices?

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander  wrote:
>> Here is what I have, 6 votes clearly stated:
>> 1. Rename nothing: Daniel,
>> 2. Rename directory only: Andres
>> 3. Rename everything: Stephen, Vladimir, David S, Michael P (with
>> aliases for functions, I could live without at this point...)
>
> Put my vote down for 2.

I think there is a very strong consensus for going either forward and
renaming everything or going backward and renaming nothing.  That
position has been endorsed by me, David Johnston, Tom Lane, Stephen
Frost, Kevin Grittner, Vladimir Rusinov, David Steele, probably
Michael Paquier, and possibly JD.  The only people who have explicitly
voted against that position are Andres and Magnus, who prefer renaming
only the directory.  I think that's approximately a 7-2 vote in favor
of not leaving things as they are (#2).

The vote on whether to go forward (#3) or backward (#1) is closer.
All of the people mentioned above as wanting consistency - except for
JD whose actual vote wasn't entirely clear - indicated a preference
for #3 over #1, but a number of them prefer it only weakly.  Moreover,
Fujii Masao and Daniel Verite prefer #1.  But I still think that the
vote is in favor of #3.  There are 7 clear votes for that position and
no more than 2 votes for any other position.  Even regarding every
vote that isn't for #3 as a vote for #1, which is probably not
entirely accurate, it's still 7-4 in favor of #3.

Looking back at older emails before things came quite so sharply into
focus, I found various other opinions.  But I don't think they change
the overall picture very much.  Cynthia Shang seemed to favor a more
limited renaming, but her point was that we have lots of internal
stuff that uses the xlog terminology, which isn't quite the same
question as whether the user-visible stuff should all match.  David
Fetter favored not adding aliases when we did the renaming, but didn't
clearly spell out that he favored the renaming.  Similarly, Euler
Taveira favored aliases in an extension, but likewise didn't clearly
spell out his position on the renaming itself.  (I would tend to count
those as votes in favor of the renaming itself but you could argue
that.)  Bruce Momjian wanted to go forward to keep things clean.
Simon Riggs wanted to leave things as they are, but the reason given
was not so much about the merits of the issue but about not wanting to
spend more time on it.  You can come up with different counts
depending on exactly how you interpret what all of those people said,
but not even the least favorable allocation of those votes ends up
with anything other than #3 as the most popular option.

Therefore, I plan to go ahead and do #3.  Somebody's probably going to
jump in now with another opinion but I think this thread's gone on
long enough.  We're going to take some backward-compatibility pain
here as a result of these changes and some people are going to be
unhappy about that, but I think we've allowed enough time for people
to weigh in with opinions and this seems to be where we're at.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Magnus Hagander]

On Mon, Feb 6, 2017 at 5:24 AM, Michael Paquier 
wrote:

> On Sat, Feb 4, 2017 at 6:39 AM, Robert Haas  wrote:
> > On Fri, Feb 3, 2017 at 5:21 AM, Stephen Frost 
> wrote:
> >> Daniel,
> >>
> >> * Daniel Verite (dan...@manitou-mail.org) wrote:
> >>> What if we look at the change from the pessimistic angle?
> >>> An example of confusion that the change would create:
> >>> a lot of users currently choose pg_wal for the destination
> >>> directory of their archive command. Less-informed users
> >>> that set up archiving and/or log shipping in PG10 based on
> >>> advice online from previous versions will be fairly
> >>> confused about the missing pg_xlog, and the fact that the
> >>> pg_wal directory they're supposed to create already exists.
> >>
> >> One would hope that they would realize that's not going to work
> >> when they set up PG10.  If they aren't paying attention sufficient
> >> to realize that then it seems entirely likely that they would feel
> >> equally safe removing the contents of a directory named 'pg_xlog'.
> >
> > So... somebody want to tally up the votes here?
>
> Here is what I have, 6 votes clearly stated:
> 1. Rename nothing: Daniel,
> 2. Rename directory only: Andres
> 3. Rename everything: Stephen, Vladimir, David S, Michael P (with
> aliases for functions, I could live without at this point...)
>

Put my vote down for 2.



> > And... was this discussed at the FOSDEM developer meeting?
> >
> > (Please say yes.)
>
> Looking only at the minutes, the answer is no:
> https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2017_Developer_Meeting



We discussed discussing it :) And came to the conclusion that we did not
have enough of a quorum to actually make any decision on it complete, so we
figured it's better if everybody just chime in individually.


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Fujii Masao]

On Mon, Feb 6, 2017 at 1:24 PM, Michael Paquier
 wrote:
> On Sat, Feb 4, 2017 at 6:39 AM, Robert Haas  wrote:
>> On Fri, Feb 3, 2017 at 5:21 AM, Stephen Frost  wrote:
>>> Daniel,
>>>
>>> * Daniel Verite (dan...@manitou-mail.org) wrote:
 What if we look at the change from the pessimistic angle?
 An example of confusion that the change would create:
 a lot of users currently choose pg_wal for the destination
 directory of their archive command. Less-informed users
 that set up archiving and/or log shipping in PG10 based on
 advice online from previous versions will be fairly
 confused about the missing pg_xlog, and the fact that the
 pg_wal directory they're supposed to create already exists.
>>>
>>> One would hope that they would realize that's not going to work
>>> when they set up PG10.  If they aren't paying attention sufficient
>>> to realize that then it seems entirely likely that they would feel
>>> equally safe removing the contents of a directory named 'pg_xlog'.
>>
>> So... somebody want to tally up the votes here?
>
> Here is what I have, 6 votes clearly stated:
> 1. Rename nothing: Daniel,
> 2. Rename directory only: Andres
> 3. Rename everything: Stephen, Vladimir, David S, Michael P (with
> aliases for functions, I could live without at this point...)

I vote for 1.
I still wonder how much the renaming of pg_xlog actually helps very careless
people who remove pg_xlog becase its name includes "log". I'm afraid that
they would make another serious mistake (e.g., remove pg_wal because it has
many files and it occupies large amount of disk space) even after renaming
to pg_wal. The crazy idea, making initdb create the empty file with the name
"DONT_REMOVE_pg_xlog_IF_YOU_DONT_WANT_TO_LOSE_YOUR_IMPORTANT_DATA"
in $PGDATA seems more helpful. Anyway I'm afraid that the renaming would
cause more pain than gain.

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Kevin Grittner]

On Sun, Feb 5, 2017 at 10:24 PM, Michael Paquier
 wrote:

>> So... somebody want to tally up the votes here?
>
> Here is what I have, 6 votes clearly stated:
> 1. Rename nothing: Daniel,
> 2. Rename directory only: Andres
> 3. Rename everything: Stephen, Vladimir, David S, Michael P (with
> aliases for functions, I could live without at this point...)

I vote for 3 as well, with 1 as the only sane alternative.

-- 
Kevin Grittner


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Michael Paquier]

On Sat, Feb 4, 2017 at 6:39 AM, Robert Haas  wrote:
> On Fri, Feb 3, 2017 at 5:21 AM, Stephen Frost  wrote:
>> Daniel,
>>
>> * Daniel Verite (dan...@manitou-mail.org) wrote:
>>> What if we look at the change from the pessimistic angle?
>>> An example of confusion that the change would create:
>>> a lot of users currently choose pg_wal for the destination
>>> directory of their archive command. Less-informed users
>>> that set up archiving and/or log shipping in PG10 based on
>>> advice online from previous versions will be fairly
>>> confused about the missing pg_xlog, and the fact that the
>>> pg_wal directory they're supposed to create already exists.
>>
>> One would hope that they would realize that's not going to work
>> when they set up PG10.  If they aren't paying attention sufficient
>> to realize that then it seems entirely likely that they would feel
>> equally safe removing the contents of a directory named 'pg_xlog'.
>
> So... somebody want to tally up the votes here?

Here is what I have, 6 votes clearly stated:
1. Rename nothing: Daniel,
2. Rename directory only: Andres
3. Rename everything: Stephen, Vladimir, David S, Michael P (with
aliases for functions, I could live without at this point...)

> And... was this discussed at the FOSDEM developer meeting?
>
> (Please say yes.)

Looking only at the minutes, the answer is no:
https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2017_Developer_Meeting
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Kevin Grittner]

On Thu, Jan 26, 2017 at 3:55 PM, Robert Haas  wrote:

> The substantive issue here is whether we should go forward with this
> change, back out the change we already did, or leave things as they
> are.  Tom, David, and I seem to be in lock step on at least the
> following conclusion: halfway in between is bad.

I agree.

> So I have every
> intention of continuing to push very hard for us to go either forward
> or backward.

+1

Given the number of times I've known of people deleting files from
pg_xlog because the name made the contents seem unimportant, I
think finishing the job is better.

--
Kevin Grittner
EDB: 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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Fri, Feb 3, 2017 at 5:21 AM, Stephen Frost  wrote:
> Daniel,
>
> * Daniel Verite (dan...@manitou-mail.org) wrote:
>> What if we look at the change from the pessimistic angle?
>> An example of confusion that the change would create:
>> a lot of users currently choose pg_wal for the destination
>> directory of their archive command. Less-informed users
>> that set up archiving and/or log shipping in PG10 based on
>> advice online from previous versions will be fairly
>> confused about the missing pg_xlog, and the fact that the
>> pg_wal directory they're supposed to create already exists.
>
> One would hope that they would realize that's not going to work
> when they set up PG10.  If they aren't paying attention sufficient
> to realize that then it seems entirely likely that they would feel
> equally safe removing the contents of a directory named 'pg_xlog'.

So... somebody want to tally up the votes here?

And... was this discussed at the FOSDEM developer meeting?

(Please say yes.)

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

Daniel,

* Daniel Verite (dan...@manitou-mail.org) wrote:
> What if we look at the change from the pessimistic angle?
> An example of confusion that the change would create:
> a lot of users currently choose pg_wal for the destination
> directory of their archive command. Less-informed users
> that set up archiving and/or log shipping in PG10 based on
> advice online from previous versions will be fairly
> confused about the missing pg_xlog, and the fact that the
> pg_wal directory they're supposed to create already exists.

One would hope that they would realize that's not going to work
when they set up PG10.  If they aren't paying attention sufficient
to realize that then it seems entirely likely that they would feel
equally safe removing the contents of a directory named 'pg_xlog'.

> Also googling for pg_wal, I'm finding food for thought like this
> IBM technote:
> http://www-01.ibm.com/support/docview.wss?uid=isg3T1015637
> which recommends to 
> "Remove all files under /var/lib/pgsql/9.0/data/pg_wal/"
> and also calls that directory the "write-ahead log directory"
> which is quite confusing because apparently it's the destination of
> their archive command.

It's certainly unfortunate that people have thought that they can create
arbitrary directories under the PG data directory.  That's never going
to be safe, witness that we've created new directories under PGDATA in
the last few releases and I don't see any reason why that would change
moving forward.  Perhaps we should check for the existance of such a
directory during pg_upgrade and throw an error, and we should go back
and do the same for other directories which have been added over
releases, but I'm not sure I can see an argument for doing much more
than that.

> This brings the question: what about the people who will delete
> their pg_wal (ex-pg_xlog) when they face a disk-full condition and
> they mix up in their mind the archive directory and the WAL directory?

In my experience, at least, that's less likely to happen than someone
nuke'ing pg_xlog.

> It's hard to guess how many could make that mistake but I don't see
> why it would be less probable than confusing pg_xlog and pg_log.

Based on my experience, at least, that seems quite a bit less likely to
happen.

> At least the contents of the latter directories look totally
> different, contrary to the wal directory versus wal archive.

Sadly, that doesn't seem to have always made much of a difference.

> Also, what about the users who are helped currently by
> the fact that "pg_xlog" is associated at the top of google results
> to good articles that explain what it is, why it fills up and what
> to do about it? By burying the name "pg_xlog" we're also loosing that
> connection, and in the worst case making worse the problem we
> wanted to help with.

We'll have new articles about pg_wal which will be picked up by Google
also.  I'm not quite sure how we would be making the problem worse
though- previously when it filled, a group of users believed it to be a
log directory which could be wiped out.  With the new name, it's at
least clearer that it's not simple a directory of not-necessary log
files.

> There's also the disruption in existing backup scripts that directly
> reference pg_xlog. Obviously these scripts are critical, and there's
> something weird in breaking that intentionally. The motivation of the
> breakage is likely to be felt as frivolous and unfair to those people who
> are adversely impacted by the change, even if the part of not
> reading the release notes is their fault.

While these scripts are critical, they're also likely to not be safe,
which is the unfortunate reality.  If they're well written then they'll
break cleanly, quickly, and be easily fixed.

We will break things across major version upgrades.  That's part of
the reason that we have major version upgrades, and why we support
released versions for years with bug fixes.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Michael Paquier]

On Fri, Feb 3, 2017 at 8:50 AM, Daniel Verite  wrote:
> What if we look at the change from the pessimistic angle?
> An example of confusion that the change would create:
> a lot of users currently choose pg_wal for the destination
> directory of their archive command.

Really? I find that surprising to say "a lot". Perhaps there are some,
but first I would not suspect that there are many people to use this
repository name, and even less crazy enough to store them directly in
PGDATA itself. And of course that's not on a different partition :)

> Also googling for pg_wal, I'm finding food for thought like this
> IBM technote:
> http://www-01.ibm.com/support/docview.wss?uid=isg3T1015637
> which recommends to
> "Remove all files under /var/lib/pgsql/9.0/data/pg_wal/"
> and also calls that directory the "write-ahead log directory"
> which is quite confusing because apparently it's the destination of
> their archive command.

Well this product of IBM is one.

> There's also the disruption in existing backup scripts that directly
> reference pg_xlog. Obviously these scripts are critical, and there's
> something weird in breaking that intentionally. The motivation of the
> breakage is likely to be felt as frivolous and unfair to those people who
> are adversely impacted by the change, even if the part of not
> reading the release notes is their fault.

Those are not complicated to fix because they are hard failures.
Sufficient tests need to be done so as backup scripts don't show in
red on live systems before deploying them. The original reason to do
the rename is that there are folks as well thinking that removing
pg_xlog is fine on full disk because, you know, it contains just
*logs* so they are not critical for the system.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Daniel Verite]

Peter Eisentraut wrote:

> You really have (at least) three options here:
> 
> 1. Rename nothing
> 2. Rename directory only
> 3. Rename everything

I vote for 1) as I believe the renaming will create more confusion
than it's worth, not even considering the renaming of functions
and views.

What if we look at the change from the pessimistic angle?
An example of confusion that the change would create:
a lot of users currently choose pg_wal for the destination
directory of their archive command. Less-informed users
that set up archiving and/or log shipping in PG10 based on
advice online from previous versions will be fairly
confused about the missing pg_xlog, and the fact that the
pg_wal directory they're supposed to create already exists.

Also googling for pg_wal, I'm finding food for thought like this
IBM technote:
http://www-01.ibm.com/support/docview.wss?uid=isg3T1015637
which recommends to 
"Remove all files under /var/lib/pgsql/9.0/data/pg_wal/"
and also calls that directory the "write-ahead log directory"
which is quite confusing because apparently it's the destination of
their archive command.

This brings the question: what about the people who will delete
their pg_wal (ex-pg_xlog) when they face a disk-full condition and
they mix up in their mind the archive directory and the WAL directory?
It's hard to guess how many could make that mistake but I don't see
why it would be less probable than confusing pg_xlog and pg_log.
At least the contents of the latter directories look totally
different, contrary to the wal directory versus wal archive.

Also, what about the users who are helped currently by
the fact that "pg_xlog" is associated at the top of google results
to good articles that explain what it is, why it fills up and what
to do about it? By burying the name "pg_xlog" we're also loosing that
connection, and in the worst case making worse the problem we
wanted to help with.

There's also the disruption in existing backup scripts that directly
reference pg_xlog. Obviously these scripts are critical, and there's
something weird in breaking that intentionally. The motivation of the
breakage is likely to be felt as frivolous and unfair to those people who
are adversely impacted by the change, even if the part of not
reading the release notes is their fault.


Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Michael Paquier]

On Mon, Jan 30, 2017 at 8:01 PM, Vladimir Rusinov  wrote:
>
> On Fri, Jan 27, 2017 at 11:03 PM, Peter Eisentraut
>  wrote:
>>
>> 1. Rename nothing
>> 2. Rename directory only
>> 3. Rename everything
>
>
> 3 or 1 (with a slight preference for 3).
>
> Not sure if my vote counts, but for me as ex-DBA consistency mattered a lot.

Any voice counts :)

> This is one of the reasons PostgreSQL is actually nicer to work with than
> many other databases. I remember 'wal' vs 'xlog' was actually one of a very
> few confusing things. I think it is important to stick to just one term,
> whether it be wal or xlog. I'd prefer wal since it's a term used in many
> other systems. 'xlog' may be confused with likes of binary log in MySQL
> which is not what it is.

The first time I worked on Postgres, I was not able to do the mapping
between both terms as well.

> Now, I've rebased my patches to rename functions (with and without aliases)
> on top of current master, but there's probably no point of posting them now
> given there are patches above that rename other things as well.

OK, I have moved this patch to CF 2017-03, let's make the discussion
continue with more votes coming in.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Vladimir Rusinov]

On Fri, Jan 27, 2017 at 11:03 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:

> 1. Rename nothing
> 2. Rename directory only
> 3. Rename everything
>

3 or 1 (with a slight preference for 3).

Not sure if my vote counts, but for me as ex-DBA consistency mattered *a
lot*.
This is one of the reasons PostgreSQL is actually nicer to work with than
many other databases. I remember 'wal' vs 'xlog' was actually one of a very
few confusing things. I think it is important to stick to just one term,
whether it be wal or xlog. I'd prefer wal since it's a term used in many
other systems. 'xlog' may be confused with likes of binary log in MySQL
which is not what it is.

Now, I've rebased my patches to rename functions (with and without aliases)
on top of current master, but there's probably no point of posting them now
given there are patches above that rename other things as well.

-- 
Vladimir Rusinov
Storage SRE, Google Ireland

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-28 08:47:03 +0900, Michael Paquier wrote:
> > On Sat, Jan 28, 2017 at 8:03 AM, Peter Eisentraut
> >  wrote:
> > > On 1/26/17 2:05 PM, Robert Haas wrote:
> > >> I do not think it can be right to rename the directory and not
> > >> anything else.
> > >
> > > I think this is the root of the confusion.
> > >
> > > A lot of people apparently consented to renaming pg_xlog with the
> > > understanding that that's it, whereas other people understood it as
> > > consensus for renaming everything.
> > >
> > > You really have (at least) three options here:
> > >
> > > 1. Rename nothing
> > > 2. Rename directory only
> > > 3. Rename everything
> > >
> > > and you need to count the votes of each pair separately.
> > 
> > 4. Rename everything with aliases.
> > 
> > I would vote for 4., or 3. for consistency if 4. is not an eligible choice.
> 
> 2, 4, 1, 3

For me, it's: 3, 4, 1, 2.

I tend to agree with the other discussion, which points out that aliases
for everything isn't really practical..

Of course, I'd also like to drop things like pg_user and pg_shadow one
day...  Never thought they'd last anywhere near this long when I first
wrote those views, 12 years ago...

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-01-28 08:47:03 +0900, Michael Paquier wrote:
> On Sat, Jan 28, 2017 at 8:03 AM, Peter Eisentraut
>  wrote:
> > On 1/26/17 2:05 PM, Robert Haas wrote:
> >> I do not think it can be right to rename the directory and not
> >> anything else.
> >
> > I think this is the root of the confusion.
> >
> > A lot of people apparently consented to renaming pg_xlog with the
> > understanding that that's it, whereas other people understood it as
> > consensus for renaming everything.
> >
> > You really have (at least) three options here:
> >
> > 1. Rename nothing
> > 2. Rename directory only
> > 3. Rename everything
> >
> > and you need to count the votes of each pair separately.
> 
> 4. Rename everything with aliases.
> 
> I would vote for 4., or 3. for consistency if 4. is not an eligible choice.

2, 4, 1, 3


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Michael Paquier]

On Sat, Jan 28, 2017 at 12:43 PM, David Steele  wrote:
> The problem I have with aliases is that they would need to be done across
> the board.  At the least, we would need function aliases, symlinks for the
> binaries (which would rneed to be done by the packagers), aliases for the
> command line options, and lots of notations in the documentation.

I was not precise enough here, I am fine with only the function
aliases, because they just have as cost an extra line in pg_proc.h and
because binary-level aliases on Windows are a pain.

> All of this would need to be preserved more or less indefinitely, because if
> we can't decide on a break now it's not likely to happen later.

That's true as well.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[David Steele]

On 1/27/17 6:47 PM, Michael Paquier wrote:

On Sat, Jan 28, 2017 at 8:03 AM, Peter Eisentraut
 wrote:

On 1/26/17 2:05 PM, Robert Haas wrote:

I do not think it can be right to rename the directory and not
anything else.


I think this is the root of the confusion.

A lot of people apparently consented to renaming pg_xlog with the
understanding that that's it, whereas other people understood it as
consensus for renaming everything.

You really have (at least) three options here:

1. Rename nothing
2. Rename directory only
3. Rename everything

and you need to count the votes of each pair separately.


4. Rename everything with aliases.

I would vote for 4., or 3. for consistency if 4. is not an eligible choice.


I vote for 3.

The problem I have with aliases is that they would need to be done 
across the board.  At the least, we would need function aliases, 
symlinks for the binaries (which would rneed to be done by the 
packagers), aliases for the command line options, and lots of notations 
in the documentation.


All of this would need to be preserved more or less indefinitely, 
because if we can't decide on a break now it's not likely to happen later.


--
-David
da...@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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Michael Paquier]

On Sat, Jan 28, 2017 at 8:03 AM, Peter Eisentraut
 wrote:
> On 1/26/17 2:05 PM, Robert Haas wrote:
>> I do not think it can be right to rename the directory and not
>> anything else.
>
> I think this is the root of the confusion.
>
> A lot of people apparently consented to renaming pg_xlog with the
> understanding that that's it, whereas other people understood it as
> consensus for renaming everything.
>
> You really have (at least) three options here:
>
> 1. Rename nothing
> 2. Rename directory only
> 3. Rename everything
>
> and you need to count the votes of each pair separately.

4. Rename everything with aliases.

I would vote for 4., or 3. for consistency if 4. is not an eligible choice.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-01-27 18:06:11 -0500, Peter Eisentraut wrote:
> On 1/24/17 4:47 PM, Robert Haas wrote:
> > I'm not excited about starting to change pg_clog before we finish with
> > xlog -> wal.  Then we just have two half-done things, IMO.  But I'm
> > also not the only one with a commit bit.
> 
> I think that depends on which way you slice the overall mission.  You
> appear to think the mission is to have everything named consistently.  I
> thought the mission was to have no directories named *log*.

+1


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Michael Paquier]

On Sat, Jan 28, 2017 at 8:06 AM, Peter Eisentraut
 wrote:
> On 1/24/17 4:47 PM, Robert Haas wrote:
>> I'm not excited about starting to change pg_clog before we finish with
>> xlog -> wal.  Then we just have two half-done things, IMO.  But I'm
>> also not the only one with a commit bit.
>
> I think that depends on which way you slice the overall mission.  You
> appear to think the mission is to have everything named consistently.  I
> thought the mission was to have no directories named *log*.

Those are two different missions. Deciding what to do for the renaming
of pg_xlog does not prevent pg_clog and pg_subtrans to be renamed as
no functions and no binaries use those terms.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Peter Eisentraut]

On 1/24/17 4:47 PM, Robert Haas wrote:
> I'm not excited about starting to change pg_clog before we finish with
> xlog -> wal.  Then we just have two half-done things, IMO.  But I'm
> also not the only one with a commit bit.

I think that depends on which way you slice the overall mission.  You
appear to think the mission is to have everything named consistently.  I
thought the mission was to have no directories named *log*.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Peter Eisentraut]

On 1/26/17 1:10 PM, Tom Lane wrote:
> pg_reset_wal

It's really more pg_reset_controldata, isn't it?

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Peter Eisentraut]

On 1/26/17 2:05 PM, Robert Haas wrote:
> I do not think it can be right to rename the directory and not
> anything else.

I think this is the root of the confusion.

A lot of people apparently consented to renaming pg_xlog with the
understanding that that's it, whereas other people understood it as
consensus for renaming everything.

You really have (at least) three options here:

1. Rename nothing
2. Rename directory only
3. Rename everything

and you need to count the votes of each pair separately.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Michael Paquier]

On Fri, Jan 27, 2017 at 2:21 AM, Robert Haas  wrote:
> On Tue, Jan 24, 2017 at 4:47 PM, Robert Haas  wrote:
>>> But I don't see any proposals to actually change all uses of "xlog" to
>>> "wal".  What about program names, command line options, etc.?  If the
>>> argument is, we changed one thing, we should change the rest, then let's
>>> see that.  I think that argument itself is flawed, but if that's what
>>> we're going with, let's see the whole plan.
>>
>> I'm happy to go change every last bit of it.  I was expecting after I
>> committed the initial rename that somebody would provide a follow-on
>> patch to do the rest of it in short order.  Instead, months went by
>> and we still don't have a complete patch.  But I don't see why that
>> has to take more than a day's work, probably just a few hours.  I'd
>> like to do that and move on.
>
> And here are patches for that.
> 0001 renames everything that contains "xlog" in pg_proc.h to refer to "wal".
> 0002 renames programs whose names contains "xlog".
> 0003 renames the dtrace probes whose names contain "xlog".
> 0004 renames command line options which contain "xlog".
>
> There are probably a few more things that could be done afterwards to
> clean up other odds and ends, but I think this gets the vast bulk of
> the user-visible references to xlog.

Thanks for doing this work. Jumping on the train, here is a review for
those patches. All of them are very mechanical changes. Just:
-
+
 
A nit about the number of spaces here.

In protocol.sgml:
  
  
   xlogpos (text)
  
  
  
   Current xlog flush location. Useful to get a known location in the
   transaction log where streaming can start.
  
  
  
You want to say WAL here instead of xlog.

In storage.sgml, similar thing:
  
   pd_lsn
   PageXLogRecPtr
   8 bytes
   LSN: next byte after last byte of xlog record for last change
   to this page
  
s/xlog/WAL/

In pg_standby.c:
pg_standby.c:   printf("  %s [OPTION]... ARCHIVELOCATION NEXTWALFILE
XLOGFILEPATH [RESTARTWALFILE]\n", progname);
s/XLOGFILEPATH/WALFILEPATH/.

All the other references to "xlog" are in the code comments, for the
user-facing changes your set of patches is enough.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

Andres,

* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-26 19:01:54 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > I hear these complaints about postgres most frequently: 1) replication
> > > sucks. 2) way too slow on analytics queries. 3) existing admin tools
> > > suck. 4) self written admin tools (required due to 3)) constantly break.
> > > 
> > > There's a lot being done on 1) and 2). There's very little in-core
> > > progress about 3). We're getting worse on 4).
> > 
> > I certainly hear some of these complaints also, and I'd love it if '3'
> > were something that the project was focused on, but, well, I really
> > don't see pgAdmin ever being in core, and 99% of the time that I'm
> > talking to end users, that's really what they're looking for (or, well,
> > something like it).  I don't recall, off-hand at least, ever running
> > into a user complaining that their pgAdmin-like admin tool broke.
> 
> For me it's it's not a pgadmin alike (or rather a more featureful
> version) that's breaking the camel's back.  By far the biggest one I
> hear is auto-HA.  There's no in-core support, and pretty much all of the
> stuff out there is immature as hell.

Oh, that's not what I tend to think of as 'admin tool'.  I completely
agree with you on #1 and also that we need something better for HA.

> And even if it weren't people for
> good reason don't trust such core aspects to $random_project.  Good,
> easy to set up, monitoring is another thing - and I don't thing
> check_postgres is a significant portion of that, it doesn't have much in
> the way of guidelines, and actually pointing people to where problems
> are.

My comment with check_postgres was more of a 'it seems unlikely we would
get in something as simple as this', not to suggest in any way that it's
the end-all, be-all of monitoring.

And now to, unashamedly, push my own agenda- any ideas about something
that would help with any of this that could be accomplished over a
summer by a student?  Even if you don't want to mentor, having a good
description, what skills are needed, the difficulty level, and the
expected outcomes might allow someone else to mentor...

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-01-26 19:01:54 -0500, Stephen Frost wrote:
> Andres,
> 
> * Andres Freund (and...@anarazel.de) wrote:
> > I hear these complaints about postgres most frequently: 1) replication
> > sucks. 2) way too slow on analytics queries. 3) existing admin tools
> > suck. 4) self written admin tools (required due to 3)) constantly break.
> > 
> > There's a lot being done on 1) and 2). There's very little in-core
> > progress about 3). We're getting worse on 4).
> 
> I certainly hear some of these complaints also, and I'd love it if '3'
> were something that the project was focused on, but, well, I really
> don't see pgAdmin ever being in core, and 99% of the time that I'm
> talking to end users, that's really what they're looking for (or, well,
> something like it).  I don't recall, off-hand at least, ever running
> into a user complaining that their pgAdmin-like admin tool broke.

For me it's it's not a pgadmin alike (or rather a more featureful
version) that's breaking the camel's back.  By far the biggest one I
hear is auto-HA.  There's no in-core support, and pretty much all of the
stuff out there is immature as hell. And even if it weren't people for
good reason don't trust such core aspects to $random_project.  Good,
easy to set up, monitoring is another thing - and I don't thing
check_postgres is a significant portion of that, it doesn't have much in
the way of guidelines, and actually pointing people to where problems
are.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

Andres,

* Andres Freund (and...@anarazel.de) wrote:
> I hear these complaints about postgres most frequently: 1) replication
> sucks. 2) way too slow on analytics queries. 3) existing admin tools
> suck. 4) self written admin tools (required due to 3)) constantly break.
> 
> There's a lot being done on 1) and 2). There's very little in-core
> progress about 3). We're getting worse on 4).

I certainly hear some of these complaints also, and I'd love it if '3'
were something that the project was focused on, but, well, I really
don't see pgAdmin ever being in core, and 99% of the time that I'm
talking to end users, that's really what they're looking for (or, well,
something like it).  I don't recall, off-hand at least, ever running
into a user complaining that their pgAdmin-like admin tool broke.

I have doubts that we could even get something like check_postgres or
another monitoring type of tool into core, though it would be so
nice to have tight integration between montioring and the core code.
That would require some kind of pluggable system which could support the
montioring-of-the-day and an easy way to extend it and a way to set up
what should be monitored and what shouldn't along with something to
actually gather that info while the system is running (eg: a background
worker of some kind), or at least, those are my general thoughts.

Maybe we'll get to the point where we'd have a fully-baked, featureful
backup solution that works with large-scale systems in core; I've at
least got some hopes of that happening, but not any particular timeline
or expectation of it happening soon.

Having a good way to do logging of different levels to different
locations would also be really nice, because our current logging
situation is really rather terrible.

> > I actually took your response as: "why the f**k is he talking about
> > camels?" and started laughing...
> 
> That's good then, and let's raise a $beverage_of_choice tonight to the
> fallability of e-mail conversation ;)

Hah, now that I can certainly agree with..

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[David G. Johnston]

On Thu, Jan 26, 2017 at 4:19 PM, Andres Freund  wrote:

>
> We decided s/pg_xlog/pg_wal/ was necessary because people lost their
> data, and we couldn't come up with a reasonable way to change it without
> the name. The tradeoff is dataloss vs. dealing with directory renaming
> in a few lowlevel tools.  So we decided to change the name.  It seems
> breakage was unavoidable.
>
> For me the renaming of functions, binaries, etc, is different because
> the benefit is long-term avoidance of a bit of confusion, with the
> shorter term price being tool breakages and confusion because
> documentation/guides/... for different versions don't apply anymore, and
> the search terms don't help anymore.  But we're still changing this,
> even though breakage seems avoidable.
>

Well stated and compelling.
​

>
> And that fits into the bigger topic of us doing minor cleanups without a
> lot of concern for backward compatibility, e.g. like us whacking things
> around in pg_stat_activity for most of the last releases - nearly all of
> those could have been done in a compatible manner, without even smelling
> that badly.
>
> I hear these complaints about postgres most frequently: 1) replication
> sucks. 2) way too slow on analytics queries. 3) existing admin tools
> suck. 4) self written admin tools (required due to 3)) constantly break.
>
> There's a lot being done on 1) and 2). There's very little in-core
> progress about 3). We're getting worse on 4).
>

​I would posit, broadly, and without any evidence, that changes like we are
discussing here, will go toward helping on 3 since (hopefully) as
PostgreSQL becomes a more appealing option in the marketplace more quality
developers will be drawn toward using their skills to improve its
ecosystem.  Mandating uniformity in areas like this speaks toward
professionalism.

Given that "there's a lot being done on #1" it would seem that right now is
an excellent time to make these changes - so that the new guides and tools
that leverage those enhancements can use the WAL terminology and have its
presence be consistently present throughout the system.

If there was a reasonably short horizon for features or capabilities that
make this kind of renaming breaking easier to accommodate I would say we
could probably wait for it to be completed first.  But AFAIK there isn't
anything in the works that would allow individual users to easily enable a
backward-compatibility mode for the mid-level API that we are largely
touching here.

It may be that this is a straw that breaks the camel's back for some users
of PostgreSQL who are fed up with #4 ... I don't know ... but I'm
reasonably confident that new users a couple of years from now would have a
better experience with our product with these changes in place.  Its an
aggressive play for growth - and that entails risk and upsetting those
invested in the status-quo (which are are already doing per your #1).

David J.

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-01-26 15:45:15 -0700, David G. Johnston wrote:
> On Thu, Jan 26, 2017 at 3:28 PM, Andres Freund  wrote:
>
> > I *personally* don't think it's worth
> > changing all this without taking more care about backward compat than
> > we're apparently willing to do.  I'm ok with loosing that argument.  I
> > just don't think the previous concensus for a narrower change can be
> > used for the wider one
> > ​.
> >
>
> ​It would probably help others if you could brain dump a bit as to the
> benefit of the status-quo compared to both the 9.6 behavior and the all-in
> one.

Well, I think I've lost that argument, so I'm not sure how much effort
we should spent on litigating my opinion on it.  But here we go:

As I said somewhere upthread (when discussing the function names), I
think we're playing it too fast and loose with unnecessary changes.

We decided s/pg_xlog/pg_wal/ was necessary because people lost their
data, and we couldn't come up with a reasonable way to change it without
the name. The tradeoff is dataloss vs. dealing with directory renaming
in a few lowlevel tools.  So we decided to change the name.  It seems
breakage was unavoidable.

For me the renaming of functions, binaries, etc, is different because
the benefit is long-term avoidance of a bit of confusion, with the
shorter term price being tool breakages and confusion because
documentation/guides/... for different versions don't apply anymore, and
the search terms don't help anymore.  But we're still changing this,
even though breakage seems avoidable.


And that fits into the bigger topic of us doing minor cleanups without a
lot of concern for backward compatibility, e.g. like us whacking things
around in pg_stat_activity for most of the last releases - nearly all of
those could have been done in a compatible manner, without even smelling
that badly.

I hear these complaints about postgres most frequently: 1) replication
sucks. 2) way too slow on analytics queries. 3) existing admin tools
suck. 4) self written admin tools (required due to 3)) constantly break.

There's a lot being done on 1) and 2). There's very little in-core
progress about 3). We're getting worse on 4).


> I actually took your response as: "why the f**k is he talking about
> camels?" and started laughing...

That's good then, and let's raise a $beverage_of_choice tonight to the
fallability of e-mail conversation ;)


Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[David G. Johnston]

On Thu, Jan 26, 2017 at 3:28 PM, Andres Freund  wrote:

> I *personally* don't think it's worth
> changing all this without taking more care about backward compat than
> we're apparently willing to do.  I'm ok with loosing that argument.  I
> just don't think the previous concensus for a narrower change can be
> used for the wider one
> ​.
>

​It would probably help others if you could brain dump a bit as to the
benefit of the status-quo compared to both the 9.6 behavior and the all-in
one.

Honestly, the reference to the camel sticking their nose in a tent was
supposed to be taken humorously, the serious explanation that it meant to
convey was already very well presented by Robert.  The only reason I added
the wiki link was to give those who would have no clue about the metaphor a
chance at understanding it.

I actually took your response as:  "why the f**k is he talking about
camels?" and started laughing...

Dave

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-01-26 16:55:37 -0500, Robert Haas wrote:
> On Thu, Jan 26, 2017 at 2:37 PM, Andres Freund  wrote:
> > On 2017-01-26 14:28:01 -0500, Robert Haas wrote:
> >> On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund  wrote:
> >> >> Whether the voters recognized that fact at the time I would have to 
> >> >> concur
> >> >> that if we are going to change from xlog to wal we should be all-in.  If
> >> >> you want to vote to reject putting the whole camel in the tent I would 
> >> >> say
> >> >> its a vote for reverting the change that put the camel's nose in there 
> >> >> in
> >> >> the first place.
> >> >
> >> > WTF.
> >>
> >> I think that response is unwarranted.  I happen to agree entirely with
> >> his position.
> >
> > I don't. Considering intent imo is important. David (and you?) is
> > basically saying "screw it, you voted for that person, you aren't
> > allowed to have an opinion anymore", and that's way outside of what I
> > consider acceptable.  So, because you think it doesn't make sense to
> > view renaming pg_xlog vs pg_wal as separate from a global s/xlog/wal/,
> > nobody else can have that position.  And on top of that David's
> > underlying that argument with a metaphor that basically implies the
> > other party is getting screwed over.  Sorry, that's not the way I want
> > decisions to be made here.
>
> I'm not saying that people aren't allowed to have an opinion any more.
> I'm saying that when somebody has an opinion that is different than
> yours, you should politely disagree with it rather than saying "WTF",
> which just as a reminder expands to "What The Fuck".  Frankly, I think
> WTF is generally not a particularly useful contribution to most
> discussions, but at the very least I think it should be used with some
> kind of context.  Sending an email that says "WTF" and nothing else
> conveys nothing other than that you don't respect the author of the
> email to which you are replying, and David's response was not so
> outlandish as to deserve that.  You might as well send an email that
> says "go dire in a fire".

The WTF wasn't about David wanting to go all in or not, but the way he
framed the general discussion.  And I do find it outlandish enough to
deserve that.  To me, especially with that methaphor and link, it still
reads as "you voted for it, even if phrased a lot more narrowly, so you
now get to eat all of it". *Especially* as it's a reply to me saying
that I'm concerned about my tepid yes to s/pg_xlog/pg_wal/ being used
for a larger change.

Using the normal ~concensus type of process for a mildly controversial
breaking change is fine with me.  I *personally* don't think it's worth
changing all this without taking more care about backward compat than
we're apparently willing to do.  I'm ok with loosing that argument.  I
just don't think the previous concensus for a narrower change can be
used for the wider one.

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[David Steele]

On 1/26/17 5:07 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> And I think that's all pretty reasonable.  I don't consider this a
>> done deal yet.  I don't consider your -1 irrelevant.  But I don't
>> think it's fair to present this as if I am somehow running roughshod
>> over community process, either.  If a large crew of people show up to
>> insist that we should rename only the directories and nothing else, I
>> guess I'll have to live with that.  But I think that's a bad decision
>> that will never survive the passage of time, and there seem to be
>> several people who agree with me.
> 
> +1 (to the above, and the rest of Robert's comments on that email).
> 
> For my 2c, I'm also in the crowd of forward or back, but don't leave it
> half-done.  My preference is certainly to move forward with these
> changes, but I understand the process and if there's enough agreement
> that we just shouldn't make these changes, then we really shouldn't make
> any of them.

+1 for forward or back.  I prefer forward but would take back over the
state we're in now.

-- 
-David
da...@pgmasters.net



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Robert Haas (robertmh...@gmail.com) wrote:
> And I think that's all pretty reasonable.  I don't consider this a
> done deal yet.  I don't consider your -1 irrelevant.  But I don't
> think it's fair to present this as if I am somehow running roughshod
> over community process, either.  If a large crew of people show up to
> insist that we should rename only the directories and nothing else, I
> guess I'll have to live with that.  But I think that's a bad decision
> that will never survive the passage of time, and there seem to be
> several people who agree with me.

+1 (to the above, and the rest of Robert's comments on that email).

For my 2c, I'm also in the crowd of forward or back, but don't leave it
half-done.  My preference is certainly to move forward with these
changes, but I understand the process and if there's enough agreement
that we just shouldn't make these changes, then we really shouldn't make
any of them.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Thu, Jan 26, 2017 at 2:37 PM, Andres Freund  wrote:
> On 2017-01-26 14:28:01 -0500, Robert Haas wrote:
>> On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund  wrote:
>> >> Whether the voters recognized that fact at the time I would have to concur
>> >> that if we are going to change from xlog to wal we should be all-in.  If
>> >> you want to vote to reject putting the whole camel in the tent I would say
>> >> its a vote for reverting the change that put the camel's nose in there in
>> >> the first place.
>> >
>> > WTF.
>>
>> I think that response is unwarranted.  I happen to agree entirely with
>> his position.
>
> I don't. Considering intent imo is important. David (and you?) is
> basically saying "screw it, you voted for that person, you aren't
> allowed to have an opinion anymore", and that's way outside of what I
> consider acceptable.  So, because you think it doesn't make sense to
> view renaming pg_xlog vs pg_wal as separate from a global s/xlog/wal/,
> nobody else can have that position.  And on top of that David's
> underlying that argument with a metaphor that basically implies the
> other party is getting screwed over.  Sorry, that's not the way I want
> decisions to be made here.

I'm not saying that people aren't allowed to have an opinion any more.
I'm saying that when somebody has an opinion that is different than
yours, you should politely disagree with it rather than saying "WTF",
which just as a reminder expands to "What The Fuck".  Frankly, I think
WTF is generally not a particularly useful contribution to most
discussions, but at the very least I think it should be used with some
kind of context.  Sending an email that says "WTF" and nothing else
conveys nothing other than that you don't respect the author of the
email to which you are replying, and David's response was not so
outlandish as to deserve that.  You might as well send an email that
says "go dire in a fire".

The substantive issue here is whether we should go forward with this
change, back out the change we already did, or leave things as they
are.  Tom, David, and I seem to be in lock step on at least the
following conclusion: halfway in between is bad.  So I have every
intention of continuing to push very hard for us to go either forward
or backward.  I hope to do that politely and respectfully, but I am
not prepared to give up on that basic point unless there are a WHOLE
LOT of contrary votes, and that is just not where we are at present.
While a variety of opinions have been expressed on the patch
originally posted and while many of those people took subtly different
positions which I'm unable to summarize concisely, there was ZERO
pushback against my email volunteering to go make all of this
consistent and pushing for it to be made consistent until you showed
up to complain.  Now there is one person objecting and several people
in favor, and I think it is pretty fair to say that many of the people
who were arguing for Vladimir's original patch are still in favor of
proceeding.  Even Peter, who wasn't super-excited about Vladimir's
patch in isolation, conceded that the xlog terminology sucked and
asked for a complete patch set.  I don't think he's unequivocally in
favor of this, but he seemed to be willing to sit still for it.  After
waiting two days for further opinions, I went and wrote the patches as
promised.

And I think that's all pretty reasonable.  I don't consider this a
done deal yet.  I don't consider your -1 irrelevant.  But I don't
think it's fair to present this as if I am somehow running roughshod
over community process, either.  If a large crew of people show up to
insist that we should rename only the directories and nothing else, I
guess I'll have to live with that.  But I think that's a bad decision
that will never survive the passage of time, and there seem to be
several people who agree with me.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Joshua D. Drake]

-Hackers,

From the field. I do not care what you chose, I care that:

1. It is consistent
2. It is readable/understandable
3. It is documented
4. It is done wholesale (because of usability)

That's it. So whatever meets that criteria, let's go for it. That may 
mean that certain commands look a little off but with the goal of 
consistency that is o.k.. It becomes explainable.


JD

--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[David G. Johnston]

On Thu, Jan 26, 2017 at 12:37 PM, Andres Freund  wrote:

> On 2017-01-26 14:28:01 -0500, Robert Haas wrote:
> > On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund 
> wrote:
> > >> Whether the voters recognized that fact at the time I would have to
> concur
> > >> that if we are going to change from xlog to wal we should be all-in.
> If
> > >> you want to vote to reject putting the whole camel in the tent I
> would say
> > >> its a vote for reverting the change that put the camel's nose in
> there in
> > >> the first place.
> > >
> > > WTF.
> >
> > I think that response is unwarranted.  I happen to agree entirely with
> > his position.
>
> I don't. Considering intent imo is important. David (and you?) is
> basically saying "screw it, you voted for that person, you aren't
> allowed to have an opinion anymore", and that's way outside of what I
> consider acceptable.  So, because you think it doesn't make sense to
> view renaming pg_xlog vs pg_wal as separate from a global s/xlog/wal/,
> nobody else can have that position.  And on top of that David's
> underlying that argument with a metaphor that basically implies the
> other party is getting screwed over.  Sorry, that's not the way I want
> decisions to be made here.
>

We can think or assume all we want about what people knew or did not know
when the prior consensus to commit the directory change was reached.  At
this point it doesn't matter.  The limited point I was trying to make is
that "the small change (i.e., the camel's nose) has been made (i.e., is now
in the tent)".  Yet here we are talking about the rest of the  camel.  We
have three options: go all-in, leave the status-quo, undo the previous
action.

The past decision is immaterial and any knowledge/experience/opinions that
it may have entailed can now, on an individual basis, be neatly wrapped up
into a vote on one of those options.  No need to make assumptions about
how/why consensus on the previous decision was reached.  And, to be fair,
it is not an unreasonable assumption for Robert to make that having voted
for the small action that most of the well-informed persons on this list
were aware and implicitly understood that the underlying intent was not the
directory but rather removing "xlog" from our vocabulary and replacing it
with the more accurate "wal".  In that vein assumed consensus makes sense.

I didn't give as much credence to the "status quo" option in my original
response as I probably should have - because, frankly, I find it
unappealing.  I do accept that it is a valid position to hold, though.

David J.

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Tom Lane]

Robert Haas  writes:
> On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund  wrote:
>>> Whether the voters recognized that fact at the time I would have to concur
>>> that if we are going to change from xlog to wal we should be all-in.  If
>>> you want to vote to reject putting the whole camel in the tent I would say
>>> its a vote for reverting the change that put the camel's nose in there in
>>> the first place.

>> WTF.

> I think that response is unwarranted.  I happen to agree entirely with
> his position.

Me three.  If we're changing this at all, we should try to eliminate
"xlog" from user-visible names and docs altogether.  I was okay with the
proposal to have some redundant names in place for awhile, and I'm equally
okay with not having any; but not with being permanently schizophrenic
on 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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-01-26 14:28:01 -0500, Robert Haas wrote:
> On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund  wrote:
> >> Whether the voters recognized that fact at the time I would have to concur
> >> that if we are going to change from xlog to wal we should be all-in.  If
> >> you want to vote to reject putting the whole camel in the tent I would say
> >> its a vote for reverting the change that put the camel's nose in there in
> >> the first place.
> >
> > WTF.
> 
> I think that response is unwarranted.  I happen to agree entirely with
> his position.

I don't. Considering intent imo is important. David (and you?) is
basically saying "screw it, you voted for that person, you aren't
allowed to have an opinion anymore", and that's way outside of what I
consider acceptable.  So, because you think it doesn't make sense to
view renaming pg_xlog vs pg_wal as separate from a global s/xlog/wal/,
nobody else can have that position.  And on top of that David's
underlying that argument with a metaphor that basically implies the
other party is getting screwed over.  Sorry, that's not the way I want
decisions to be made here.

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund  wrote:
>> Whether the voters recognized that fact at the time I would have to concur
>> that if we are going to change from xlog to wal we should be all-in.  If
>> you want to vote to reject putting the whole camel in the tent I would say
>> its a vote for reverting the change that put the camel's nose in there in
>> the first place.
>
> WTF.

I think that response is unwarranted.  I happen to agree entirely with
his position.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Thu, Jan 26, 2017 at 2:13 PM, Andres Freund  wrote:
> On 2017-01-26 14:05:43 -0500, Robert Haas wrote:
>> I completely understand that position.  I have always been doubtful of
>> the value of renaming pg_xlog to pg_wal, and I'm not any more
>> dedicated to the idea now than I was when I committed that patch.  But
>> there was overwhelming support for it, consensus on a level rarely
>> seen here.
>
> I think that consistency was based on the change being a narrow
> proposition, not a license to run around and change a lot of stuff
> including the names of binary.

I'm not so sure about that.  There are a lot of people who have
supported the idea of making this consistent on THIS thread.  It's not
clear how much of a majority there is, but it's certainly no worse
than 50-50.  It's got far more affirmative votes than most patches
that go in though, I will grant, also far more negative votes.

>> I do not think it can be right to rename the directory and not
>> anything else.  I stand by what I wrote in
>>
>> https://www.postgresql.org/message-id/ca+tgmobehp2qbtmvyxg2x8pm_9utjrya-rom5xl4quya26c...@mail.gmail.com
>
> I'm tempted to quote Emerson ;).  I don't think the naming of pg_xlog
> vs. pg_wal doesn't actually have that large an impact, to change the
> dynamics of the wal vs xlog dichotomy.  Sure it's nothing you'd do in a
> new program, but neither is it very bad.

Gee, I can't imagine what Emerson quote you might be thinking about.  :-)

I think it's just never going to work to imagine that we can
indefinitely go on having a pg_resetxlog binary to reset a thing that
is no longer called xlog.  Sure, for a few years that will seem like
it makes sense, but if we didn't change it now, eventually there would
be a push to do it later.  And if that one gets shut down, there will
eventually be another push.  We'll repeatedly relitigate this whole
debate, and maybe eventually the result will be one or two more things
get changed ... and then later we'll do it again for what's left.  I
am not entirely excited about the backward-compatibility pain we're
incurring here, but I think if we don't do it all at once it's just
going to get spread out over time.  Maybe it in a universe where
PostgreSQL was controlled by a small number of people acting as one
you could hold the line, but in the actual universe people just keep
calling a vote on this sort of thing every two or three until they
win.  I don't think there's anything you or I or anyone else can say
or do that will prevent that from happening, so I'd as soon just be
done with it.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-01-26 12:23:24 -0700, David G. Johnston wrote:
> On Thu, Jan 26, 2017 at 12:13 PM, Andres Freund  wrote:
> 
> > On 2017-01-26 14:05:43 -0500, Robert Haas wrote:
> > > I completely understand that position.  I have always been doubtful of
> > > the value of renaming pg_xlog to pg_wal, and I'm not any more
> > > dedicated to the idea now than I was when I committed that patch.  But
> > > there was overwhelming support for it, consensus on a level rarely
> > > seen here.
> >
> > I think that consistency was based on the change being a narrow
> > proposition, not a license to run around and change a lot of stuff
> > including the names of binary.
> >
> >
> ​Whether the voters recognized that fact at the time I would have to concur
> that if we are going to change from xlog to wal we​ should be all-in.  If
> you want to vote to reject putting the whole camel in the tent I would say
> its a vote for reverting the change that put the camel's nose in there in
> the first place.

WTF.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[David G. Johnston]

On Thu, Jan 26, 2017 at 12:13 PM, Andres Freund  wrote:

> On 2017-01-26 14:05:43 -0500, Robert Haas wrote:
> > I completely understand that position.  I have always been doubtful of
> > the value of renaming pg_xlog to pg_wal, and I'm not any more
> > dedicated to the idea now than I was when I committed that patch.  But
> > there was overwhelming support for it, consensus on a level rarely
> > seen here.
>
> I think that consistency was based on the change being a narrow
> proposition, not a license to run around and change a lot of stuff
> including the names of binary.
>
>
​Whether the voters recognized that fact at the time I would have to concur
that if we are going to change from xlog to wal we​ should be all-in.  If
you want to vote to reject putting the whole camel in the tent I would say
its a vote for reverting the change that put the camel's nose in there in
the first place.

https://en.wikipedia.org/wiki/Camel's_nose


> > I do not think it can be right to rename the directory and not
> > anything else.  I stand by what I wrote in
> >
> > https://www.postgresql.org/message-id/CA+TgmobeHP2qbtMvYxG2x8Pm_
> 9utjrya-rom5xl4quya26c...@mail.gmail.com
>
> I'm tempted to quote Emerson ;).  I don't think the naming of pg_xlog
> vs. pg_wal doesn't actually have that large an impact, to change the
> dynamics of the wal vs xlog dichotomy.  Sure it's nothing you'd do in a
> new program, but neither is it very bad.
>

​Once I learned what "write ahead log" was it wasn't that big a deal to
understand that this particular historical implementation detail ​means I
have to associate xlog with it.  Causing wide-spread pain to lower the
comprehension bar doesn't seems like a simple win here.  I have no real
feel for how wide-spread that would be, though.  I personally wouldn't mind
it being consistent but I am not representative of the larger user base.

David J.

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-01-26 14:05:43 -0500, Robert Haas wrote:
> I completely understand that position.  I have always been doubtful of
> the value of renaming pg_xlog to pg_wal, and I'm not any more
> dedicated to the idea now than I was when I committed that patch.  But
> there was overwhelming support for it, consensus on a level rarely
> seen here.

I think that consistency was based on the change being a narrow
proposition, not a license to run around and change a lot of stuff
including the names of binary.


> I do not think it can be right to rename the directory and not
> anything else.  I stand by what I wrote in
> 
> https://www.postgresql.org/message-id/ca+tgmobehp2qbtmvyxg2x8pm_9utjrya-rom5xl4quya26c...@mail.gmail.com

I'm tempted to quote Emerson ;).  I don't think the naming of pg_xlog
vs. pg_wal doesn't actually have that large an impact, to change the
dynamics of the wal vs xlog dichotomy.  Sure it's nothing you'd do in a
new program, but neither is it very bad.

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Thu, Jan 26, 2017 at 1:21 PM, Andres Freund  wrote:
> On 2017-01-24 16:47:29 -0500, Robert Haas wrote:
>> I'm happy to go change every last bit of it.
>
> I quite regret not aggressively opining against the renaming of pg_xlog
> to pg_wal. I think the few users deleting their data don't weigh against
> renaming a bunch of tools and function for some sense of
> consistency. This will cause pain for a couple years - maybe it'll be
> worth it 6-7 releases down the line, but I doubt before that.  But then
> the original discussion was about renaming pg_xlog, not about a general
> s/xlog/$something/.

I completely understand that position.  I have always been doubtful of
the value of renaming pg_xlog to pg_wal, and I'm not any more
dedicated to the idea now than I was when I committed that patch.  But
there was overwhelming support for it, consensus on a level rarely
seen here.

I do not think it can be right to rename the directory and not
anything else.  I stand by what I wrote in

https://www.postgresql.org/message-id/ca+tgmobehp2qbtmvyxg2x8pm_9utjrya-rom5xl4quya26c...@mail.gmail.com

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-24 16:47:29 -0500, Robert Haas wrote:
> > I'm happy to go change every last bit of it.
> 
> I quite regret not aggressively opining against the renaming of pg_xlog
> to pg_wal. I think the few users deleting their data don't weigh against
> renaming a bunch of tools and function for some sense of
> consistency. This will cause pain for a couple years - maybe it'll be
> worth it 6-7 releases down the line, but I doubt before that.  But then
> the original discussion was about renaming pg_xlog, not about a general
> s/xlog/$something/.

For my 2c, I'm actually quite happy that we're finally going to start
reducing the confusion between xlog and WAL.

Let's not forget to go update the documentation to be sensible and
consistent as we're making these mechanical changes to the program
names.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Tom Lane]

Robert Haas  writes:
> Yeah, I thought about that, too, but it doesn't really seem worth it.
> If we had pg_receive_wal and pg_receive_logical, they'd be nicely
> consistent with each other, but inconsistent with practically every
> other utility we have: pg_basebackup, pg_archivecleanup,
> pg_controldata, etc.

Mmm, good point.  I was looking at pg_test_fsync and pg_test_timing,
but those are the only exceptions, and they're only quasi-user-facing
anyway.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Andres Freund]

On 2017-01-24 16:47:29 -0500, Robert Haas wrote:
> I'm happy to go change every last bit of it.

I quite regret not aggressively opining against the renaming of pg_xlog
to pg_wal. I think the few users deleting their data don't weigh against
renaming a bunch of tools and function for some sense of
consistency. This will cause pain for a couple years - maybe it'll be
worth it 6-7 releases down the line, but I doubt before that.  But then
the original discussion was about renaming pg_xlog, not about a general
s/xlog/$something/.

- Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Tom Lane]

Stephen Frost  writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> What I think might be worth considering is inserting underscores,
>> eg "pg_receive_wal", anywhere that we are running the abbreviation
>> directly against another word.  We won't get another chance.

> Wouldn't that make it 'pg_recv_wal'?  Or were you referring to the 'wal'
> as being the abbreviation?

The latter.  As far as the programs go, that would be

pg_receive_wal
pg_reset_wal
pg_wal_dump

The other cases you mention are, for the most part, words that we're
running together ("db" is the only exception) so they're not committing
double sins against readability.  Anyway, I'm not suggesting that we
should rename anything this patch isn't touching already.

regards, tom lane

PS: I'm trying hard not to open the can of worms labeled "pg_dump_wal".


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Thu, Jan 26, 2017 at 12:41 PM, Tom Lane  wrote:
> Robert Haas  writes:
>> On Thu, Jan 26, 2017 at 12:27 PM, Alvaro Herrera
>>  wrote:
>>> There have been complaints that pg_receivexlog's name is not consistent
>>> with pg_recvlogical, and I seem to recall there were some votes for
>>> renaming pg_receivexlog to match.  We could make it "pg_recvwal" now.
>
>> ... I would prefer not to go there.
>
> I agree.  "pg_recvlogical" was a badly chosen name; let's not double
> down on the error.
>
> What I think might be worth considering is inserting underscores,
> eg "pg_receive_wal", anywhere that we are running the abbreviation
> directly against another word.  We won't get another chance.

Yeah, I thought about that, too, but it doesn't really seem worth it.
If we had pg_receive_wal and pg_receive_logical, they'd be nicely
consistent with each other, but inconsistent with practically every
other utility we have: pg_basebackup, pg_archivecleanup,
pg_controldata, etc.  I'm not prepared to endorse renaming all of that
stuff just to add underscores, and frankly I don't think the style
pg_foobarbaz is really a problem.  It's a lot easier to remember "the
only underscore is after the initial pg" than it is to remember
exactly how each word was abbreviated in each context.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas  writes:
> > On Thu, Jan 26, 2017 at 12:27 PM, Alvaro Herrera
> >  wrote:
> >> There have been complaints that pg_receivexlog's name is not consistent
> >> with pg_recvlogical, and I seem to recall there were some votes for
> >> renaming pg_receivexlog to match.  We could make it "pg_recvwal" now.
> 
> > ... I would prefer not to go there.
> 
> I agree.  "pg_recvlogical" was a badly chosen name; let's not double
> down on the error.
> 
> What I think might be worth considering is inserting underscores,
> eg "pg_receive_wal", anywhere that we are running the abbreviation
> directly against another word.  We won't get another chance.

Wouldn't that make it 'pg_recv_wal'?  Or were you referring to the 'wal'
as being the abbreviation?  Or did you mean underscores between words in
general?

If we want to switch to using underscores to seperate words, then that
implies a whole lot of *additional* renaming that I'm not sure I can
really get behind...

initdb
pg_archivecleanup
pg_basebackup
pgbench
pg_controldata
pgevent (eh, not really a binary, but it's in src/bin)
pg_dumpall
pg_isready

All of those, to me at least seem fine, and I'd further be fine with
"pg_receivewal".

I haven't got any great answers wrt pg_recvlogical, though I don't
particullarly like the existing name, but that's more because I have
to ask myself how the heck one can receive a "logical"..

Then again 'pg_controldata' only works if you realize it's really
"pg_print_pg_control" or something.  It's hardly controlling any data.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Tom Lane]

Robert Haas  writes:
> On Thu, Jan 26, 2017 at 12:27 PM, Alvaro Herrera
>  wrote:
>> There have been complaints that pg_receivexlog's name is not consistent
>> with pg_recvlogical, and I seem to recall there were some votes for
>> renaming pg_receivexlog to match.  We could make it "pg_recvwal" now.

> ... I would prefer not to go there.

I agree.  "pg_recvlogical" was a badly chosen name; let's not double
down on the error.

What I think might be worth considering is inserting underscores,
eg "pg_receive_wal", anywhere that we are running the abbreviation
directly against another word.  We won't get another chance.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Thu, Jan 26, 2017 at 12:27 PM, Alvaro Herrera
 wrote:
> Robert Haas wrote:
>
>> 0002 renames programs whose names contains "xlog".
>
> There have been complaints that pg_receivexlog's name is not consistent
> with pg_recvlogical, and I seem to recall there were some votes for
> renaming pg_receivexlog to match.  We could make it "pg_recvwal" now.

Or prw.  :-)

Personally, I generally push to avoid abbreviations like receive ->
recv.  Yeah, it's a few extra characters of typing, but you can use
tab completion so it's not really a big deal I think.  And the problem
with abbreviating things is that people then have to remember whether
it was abbreviated and in exactly which way.  "Wait, was it recv or
rcv this time?"  Moreover, some of the abbreviations we've used are
potentially opaque to non-English-speakers, or in some cases even to
English speakers.  So I would prefer not to go there.  But if the
consensus is otherwise, so be it.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Alvaro Herrera]

Robert Haas wrote:

> 0002 renames programs whose names contains "xlog".

There have been complaints that pg_receivexlog's name is not consistent
with pg_recvlogical, and I seem to recall there were some votes for
renaming pg_receivexlog to match.  We could make it "pg_recvwal" now.

-- 
Álvaro Herrerahttps://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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Mon, Jan 23, 2017 at 1:55 PM, Peter Eisentraut
 wrote:
> For the record, I don't like the name "xlog" either.  It would be nice
> if we could have more consistent and intuitive naming.

Great!

> But I don't see any proposals to actually change all uses of "xlog" to
> "wal".  What about program names, command line options, etc.?  If the
> argument is, we changed one thing, we should change the rest, then let's
> see that.  I think that argument itself is flawed, but if that's what
> we're going with, let's see the whole plan.

I'm happy to go change every last bit of it.  I was expecting after I
committed the initial rename that somebody would provide a follow-on
patch to do the rest of it in short order.  Instead, months went by
and we still don't have a complete patch.  But I don't see why that
has to take more than a day's work, probably just a few hours.  I'd
like to do that and move on.

> Moreover, I see we still have the pg_clog directory.  I thought that was
> supposed to be renamed as well, to avoid confusing it with a "log"
> directory.  Surely, we should at least conclude that original chapter
> before going further.

I'm not excited about starting to change pg_clog before we finish with
xlog -> wal.  Then we just have two half-done things, IMO.  But I'm
also not the only one with a commit bit.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Vladimir Rusinov (vrusi...@google.com) wrote:
> On Mon, Jan 23, 2017 at 6:59 PM, Stephen Frost  wrote:
> > I don't have any problem with asking for a summary of the exact set of
> > changes that he's planning to make though.  My understanding is that it
> > includes changing program names, command line options, etc.
> 
> Here's what I currently have in mind:
> 
> - sql function names (current patch)
> - binaries in bin: pg_receivexlog, pg_xlogdump, pg_resetxlog

Command-line options for other binaries in bin should also be changed
(eg: initdb's --xlogdir).

Looking at the other binaries in src/bin:

pg_archivecleanup - seems ok as-is (I'll note that it's Usage mentioned
'OLDESTKEPTWALFILE' ...)
pg_basebackup - --xlog/--xlog-method/--xlogdir
pgbench - looks fine
pg_config - looks fine
pg_controldata - looks fine
pg_ctl - looks fine
pgevent - DLL, not a binary, looks ok
pg_rewind - looks fine
pg_test_fsync - looks fine
pg_test_timing - looks fine
pg_upgrade - looks fine
psql - looks fine

> - (maybe) public/exported symbols from libpq,
> e.g. libpqGetCurrentXlogInsertLocation

Hm..?  That function is just a local function in pg_rewind.  I'd be kind
of surprised if we actually had anything in libpq that needed changing
due to this and I don't see anything there in a quick look.

> - at this time I don't target internal function and filenames, but that
> could also be done if there's desire for this.

No, I don't think that'll be necessary.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Vladimir Rusinov]

On Mon, Jan 23, 2017 at 6:59 PM, Stephen Frost  wrote:

> > For the record, I don't like the name "xlog" either.  It would be nice
> > if we could have more consistent and intuitive naming.
> >
> > But I don't see any proposals to actually change all uses of "xlog" to
> > "wal".  What about program names, command line options, etc.?  If the
> > argument is, we changed one thing, we should change the rest, then let's
> > see that.  I think that argument itself is flawed, but if that's what
> > we're going with, let's see the whole plan.
>
> That is the proposal and what Vladimir is working towards, as I
> understand it, but one piece at a time rather than one big huge patch,
> as he's already stated elsewhere on this thread.
>

Correct. Since fate of this patch is not fully decided I've paused my work
on other things until this goes in in some form.


> I don't have any problem with asking for a summary of the exact set of
> changes that he's planning to make though.  My understanding is that it
> includes changing program names, command line options, etc.
>

Here's what I currently have in mind:

- sql function names (current patch)
- binaries in bin: pg_receivexlog, pg_xlogdump, pg_resetxlog
- (maybe) public/exported symbols from libpq,
e.g. libpqGetCurrentXlogInsertLocation
- at this time I don't target internal function and filenames, but that
could also be done if there's desire for this.

I'd like to have most user-visible changed checked in earlier. Stuff like
internal refactoring can be done pretty much at any point in development
cycle.

-- 
Vladimir Rusinov
Storage SRE, Google Ireland

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Michael Paquier]

On Tue, Jan 24, 2017 at 3:59 AM, Stephen Frost  wrote:
> I agree that we could probably just go ahead and switch over to starting
> on the clog changes (there was agreement somewhere about the new name
> for that too), but, well, if I was someone watching all of this
> discussion, I have to admit I probably wouldn't be too excited starting
> on another set of name changes with all of this going on.  Admittedly,
> the clog rename is a lot less user-facing and perhaps we should have
> started with it, but this is where we're at now.

There are no SQL-level functions and no binaries using the naming clog
or subtrans, so that's a good anti-complain start.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

Peter,

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/17/17 5:03 PM, Robert Haas wrote:
> > Right.  I think a lot of that stuff should also be changed.  If we
> > weren't OK with breaking compatibility, why'd we change pg_xlog ->
> > pg_wal?  If we're not willing to change other things to match, let's
> > revert that change and be done with it.
> 
> For the record, I don't like the name "xlog" either.  It would be nice
> if we could have more consistent and intuitive naming.
> 
> But I don't see any proposals to actually change all uses of "xlog" to
> "wal".  What about program names, command line options, etc.?  If the
> argument is, we changed one thing, we should change the rest, then let's
> see that.  I think that argument itself is flawed, but if that's what
> we're going with, let's see the whole plan.

That is the proposal and what Vladimir is working towards, as I
understand it, but one piece at a time rather than one big huge patch,
as he's already stated elsewhere on this thread.

I don't have any problem with asking for a summary of the exact set of
changes that he's planning to make though.  My understanding is that it
includes changing program names, command line options, etc.

> Moreover, I see we still have the pg_clog directory.  I thought that was
> supposed to be renamed as well, to avoid confusing it with a "log"
> directory.  Surely, we should at least conclude that original chapter
> before going further.

My understanding is that it is planned to be changed also, but it's
backed up behind the sudden hang-up with making progress on the xlog ->
WAL changes.

I agree that we could probably just go ahead and switch over to starting
on the clog changes (there was agreement somewhere about the new name
for that too), but, well, if I was someone watching all of this
discussion, I have to admit I probably wouldn't be too excited starting
on another set of name changes with all of this going on.  Admittedly,
the clog rename is a lot less user-facing and perhaps we should have
started with it, but this is where we're at now.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Peter Eisentraut]

On 1/17/17 5:03 PM, Robert Haas wrote:
> Right.  I think a lot of that stuff should also be changed.  If we
> weren't OK with breaking compatibility, why'd we change pg_xlog ->
> pg_wal?  If we're not willing to change other things to match, let's
> revert that change and be done with it.

For the record, I don't like the name "xlog" either.  It would be nice
if we could have more consistent and intuitive naming.

But I don't see any proposals to actually change all uses of "xlog" to
"wal".  What about program names, command line options, etc.?  If the
argument is, we changed one thing, we should change the rest, then let's
see that.  I think that argument itself is flawed, but if that's what
we're going with, let's see the whole plan.

Moreover, I see we still have the pg_clog directory.  I thought that was
supposed to be renamed as well, to avoid confusing it with a "log"
directory.  Surely, we should at least conclude that original chapter
before going further.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Michael Paquier]

On Mon, Jan 23, 2017 at 2:06 PM, Venkata B Nagothi  wrote:
>
> On Sat, Jan 14, 2017 at 5:10 AM, Vladimir Rusinov 
> wrote:
>>
>> Attached are two new version of the patch: one keeps aliases, one don't.
>
>
> Both the patches (with and without aliases) are not getting applied to the
> latest master. Below is the error -
>
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --
> |diff --git a/src/include/access/xlog_fn.h b/src/include/access/xlog_fn.h
> |index a013d047a2..a46b2f995c 100644
> |--- a/src/include/access/xlog_fn.h
> |+++ b/src/include/access/xlog_fn.h
> --
> File to patch:

xlog_fn.h is not necessary anymore as all the declarations of
functions defined in pg_proc.h are now generated automatically, so the
conflict is simple enough to resolve.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Venkata B Nagothi]

On Sat, Jan 14, 2017 at 5:10 AM, Vladimir Rusinov 
wrote:

> Attached are two new version of the patch: one keeps aliases, one don't.
>

Both the patches (with and without aliases) are not getting applied to the
latest master. Below is the error -

Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|diff --git a/src/include/access/xlog_fn.h b/src/include/access/xlog_fn.h
|index a013d047a2..a46b2f995c 100644
|--- a/src/include/access/xlog_fn.h
|+++ b/src/include/access/xlog_fn.h
--
File to patch:


Also, remove stray reference to xlog function in one of the tests.
>
> I've lost vote count. Should we create a form to calculate which one of
> the patches should be commited?
>
> If we decide to go the extension way, perhaps it can be maintained outside
> of core Postgres?
>

My take on having aliases to the functions :

In my opinion as a DBA, I agree with having no-aliases. Having functions
doing the same thing with two different names could be confusing. I have
been doing quite a number of PostgreSQL upgrades since few years, i do not
see, the function name changes as a major issue or a road-blocker in the
upgrade exercise. If the function name has changed, it has changed. It
would be a serious thing to consider during the upgrade if there is a
change in the functionality of a particular function as it needs testing. I
think, changing of the function names in the scripts and custom-tools has
to be executed and might take up a bit of extra time.

IMHO, It is not a good idea to keep aliases as this would make the DBAs
lazier to change the function names on priority in the automated
scripts/jobs/tools during the upgrades. Especially, in bigger and complex
environments where-in database environments are handled by different
multiple groups of DBAs, it could be possible that both *xlog* functions
and *wal* functions will be used up in the scripts and all of them will be
working fine and once the *xlog* functions names are completely removed,
then some of the jobs/scripts start failing.

I would vote for "no-aliases".

Regards,
Venkata Balaji N

Database Consultant

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Vladimir Rusinov]

On Wed, Jan 18, 2017 at 12:28 PM, Michael Paquier  wrote:

> On Wed, Jan 18, 2017 at 8:15 PM, Vladimir Rusinov 
> wrote:
> > On the topic of binaries, there's going to be another patch renaming
> them.
> > Those will have no aliases as it's trivial to work-around (symlinks,
> shell
> > scripts, etc) and not so trivial to implement in a portable way.
>
> On Windows that would be a pain... So let's not use symlinks for binaries.


Just to be clear, I'm not proposing that we use symlinks. Just pointing out
that workarounds are trivial for the end users.

-- 
Vladimir Rusinov
Storage SRE, Google Ireland

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Michael Paquier]

On Wed, Jan 18, 2017 at 8:15 PM, Vladimir Rusinov  wrote:
> On the topic of binaries, there's going to be another patch renaming them.
> Those will have no aliases as it's trivial to work-around (symlinks, shell
> scripts, etc) and not so trivial to implement in a portable way.

On Windows that would be a pain... So let's not use symlinks for binaries.

> I'm used to workflows with lots of small commits, so I was not able to force
> myself to include all of the renames in one diff.

That's a good habit IMO.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Vladimir Rusinov]

On Tue, Jan 17, 2017 at 10:03 PM, Robert Haas  wrote:

> Q: OK, where is my WAL stored?
> A: pg_wal
> Q: How do I reset it?
> A: pg_resetxlog
>

On the topic of binaries, there's going to be another patch renaming them.
Those will have no aliases as it's trivial to work-around (symlinks, shell
scripts, etc) and not so trivial to implement in a portable way.

I'm used to workflows with lots of small commits, so I was not able to
force myself to include all of the renames in one diff.

-- 
Vladimir Rusinov
Storage SRE, Google Ireland

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Robert Haas (robertmh...@gmail.com) wrote:
> I'm OK with continuing to use "xlog" as the user-facing name for the
> write-ahead log, and I am OK with switching to wal.  But leaving
> things in the halfway in-between state where they are right now seems
> like a mess.  It conveniences the people who happen to care about the
> names of the parts we haven't renamed yet but not the part we already
> did rename at the price of a permanent inconsistency in naming
> conventions that can't ever eliminate.  Yuck.

I'm more of a '-1' when it comes to keeping everything called "xlog",
and a '+1' on renaming everything to be WAL, since that's what we
usually refer to this thing as, but I agree with Robert that only doing
a half-way renaming is about a -1000.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Mon, Jan 16, 2017 at 10:48 PM, Fujii Masao  wrote:
> If we do that, we should vote on all the "renaming" stuff, i.e., not only
> function names but also program names like pg_receivexlog, directory names
> like clog, option names like xlogdir option of initdb, return value names of
> the functions like xlog_position in pg_create_physical_replication_slot, etc.

Right.  I think a lot of that stuff should also be changed.  If we
weren't OK with breaking compatibility, why'd we change pg_xlog ->
pg_wal?  If we're not willing to change other things to match, let's
revert that change and be done with it.  It's undeniable that there's
going to be some pain here and I'm not committed to incurring that
pain, but I don't really understand the the theory that saying that a
half-renaming will save us pain vs. a more through renaming.  If we
change some things and not others, people will have to try to remember
in which cases they now have to say xlog instead of wal and in which
cases they still have to say xlog and (perhaps) in which cases they
can choose either.  I think "xlog" is terrible naming; there is no
universe in which "x" is a reasonable short-hand for either
"transaction" or "write-ahead".

Q: OK, where is my WAL stored?
A: pg_wal
Q: How do I reset it?
A: pg_resetxlog
Q: Why is it called pg_resetxlog?
A: Because we call the transaction log "xlog".
Q: Evidently you don't.
A: Well, it used to be called pg_xlog prior to version 10, but then we
renamed it, but the tool has still got the old name.
Q: Are you kidding me?
A: No.
Q: Do you guys suck at picking names for things?
A: Yes.
Q: Wouldn't it at least be better to settle on ONE incomprehensible
abbreviation for any given concept instead of having TWO DIFFERENT
ONES?
A: Hey, look at the time.

If we don't make this all consistent, we'll be having that
conversation -- or some variant of it -- forever.  There will be
constant arguments about whether to give in and rename some more
things.  The people who are now saying that we shouldn't break
compatibility for this change (as if we haven't already) will be even
less happy when they keep having to argue against breaking
compatibility for the same thing a second time.

I'm OK with continuing to use "xlog" as the user-facing name for the
write-ahead log, and I am OK with switching to wal.  But leaving
things in the halfway in-between state where they are right now seems
like a mess.  It conveniences the people who happen to care about the
names of the parts we haven't renamed yet but not the part we already
did rename at the price of a permanent inconsistency in naming
conventions that can't ever eliminate.  Yuck.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

Peter,

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/13/17 10:18 AM, Stephen Frost wrote:
> > Certainly, check_postgres is going to have to be changed to address this
> > and, unsurprisingly, it's already had to address a variety of major
> > version differences that have been introduced over the years.
> 
> check_postgres will not need to be changed except for the actions that
> check the disk, which you don't need unless you are using archiving.

That isn't really the point though, is it?  check_postgres will need to
be changed because there are actions which check the pg_xlog directory.
That'll cause a new release, which will be the "release that works with
PG10."

Perhaps if you're following along with -hackers and know how
check_postgres works then you'll realize that you might not *have* to
upgrade your check_postgres installation if only the directory is
changed and nothing else is, but I've got a pretty hard time seeing that
as a very common user use-case.

The implication here seems to be that because the older version of
check_postgres might appear to continue working for *some* set of
actions (but not all) that we should encouarge users to keep using that
older version with PG10.  That doesn't make any sense to me and I
certainly don't agree with it.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Peter Eisentraut]

On 1/13/17 10:18 AM, Stephen Frost wrote:
> The point I was making was that serious montioring systems would have to
> be changed and I stand by that.

I don't think my monitoring systems are any less serious than yours.

> Certainly, check_postgres is going to have to be changed to address this
> and, unsurprisingly, it's already had to address a variety of major
> version differences that have been introduced over the years.

check_postgres will not need to be changed except for the actions that
check the disk, which you don't need unless you are using archiving.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Fujii Masao]

On Sat, Jan 14, 2017 at 3:10 AM, Vladimir Rusinov  wrote:
> Attached are two new version of the patch: one keeps aliases, one don't.
> Also, remove stray reference to xlog function in one of the tests.
>
> I've lost vote count. Should we create a form to calculate which one of the
> patches should be commited?

If we do that, we should vote on all the "renaming" stuff, i.e., not only
function names but also program names like pg_receivexlog, directory names
like clog, option names like xlogdir option of initdb, return value names of
the functions like xlog_position in pg_create_physical_replication_slot, etc.

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Alvaro Herrera]

Robert Haas wrote:

> From a technical point of view, that is pretty much true.  But from a
> user perspective, I don't think it is.  If the old names live in an
> extension, then they will not be there by default.  Tools and scripts
> will break.  If that's a problem for a particular user, they an
> install the extension to unbreak those things, but tool authors will
> probably be motivated to upgrade their tools so that the extension is
> no longer needed.  Therefore, if we eventually drop the extension,
> there will probably be few users relying on it at that point.  On the
> other hand, if we install aliases that are present in every install -
> and that are not even optionally removable - a lot of people are not
> going to bother using the new names at all.  They'll just keep on
> using the old ones so that their tools work with both old and new
> versions, and if we eventually rip the stuff out of pg_proc.h it will
> cause almost as much howling as if we'd done it right at the
> beginning.
> 
> In other words, adding an extension is the only option that I see
> which will give tool authors a strong incentive to support the new
> names without making it a hard requirement on day one.

A compatibility extension sounds like a pretty decent idea to me,
considering this point.  I think breakage without a workaround will
cause people to defer migration more than they otherwise would; the
extension gives them an easy way forward while they set up their
internal code to the new reality, to test the other new things in pg10.

If we keep the extension forever, so what?  It's not like tsearch2
causes us too much of a maintenance pain.  It's been patched a few
times, but only to change things that wouldn't need changes in a
xlog->wal aliases-only module.  Anyway, I would mark the module as
deprecated with an intent of removing it in half a dozen releases or so.

-- 
Álvaro Herrerahttps://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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Robert Haas]

On Thu, Jan 12, 2017 at 1:12 PM, Tom Lane  wrote:
> Vladimir Rusinov  writes:
>> On Thu, Jan 12, 2017 at 4:57 PM, Euler Taveira  wrote:
>>> As Robert suggested in the other email: extension to create old names.
>
>> I don't follow the reasoning for the extension. It seem to have downsides
>> of both alternatives combined: we still break people's code, and we add
>> even more maintenance burden than just keeping aliases.
>
> Yeah, I'm not terribly for the extension idea.  Robert cited the precedent
> of contrib/tsearch2, but I think the history of that is a good argument
> against this: tsearch2 is still there 9 years later and there's no
> indication that we'll ever get rid of it.  We can let things rot
> indefinitely in core too.  If we do ever agree to get rid of the aliases,
> stripping them out of pg_proc.h will not be any harder than removing
> a contrib directory would be.

>From a technical point of view, that is pretty much true.  But from a
user perspective, I don't think it is.  If the old names live in an
extension, then they will not be there by default.  Tools and scripts
will break.  If that's a problem for a particular user, they an
install the extension to unbreak those things, but tool authors will
probably be motivated to upgrade their tools so that the extension is
no longer needed.  Therefore, if we eventually drop the extension,
there will probably be few users relying on it at that point.  On the
other hand, if we install aliases that are present in every install -
and that are not even optionally removable - a lot of people are not
going to bother using the new names at all.  They'll just keep on
using the old ones so that their tools work with both old and new
versions, and if we eventually rip the stuff out of pg_proc.h it will
cause almost as much howling as if we'd done it right at the
beginning.

In other words, adding an extension is the only option that I see
which will give tool authors a strong incentive to support the new
names without making it a hard requirement on day one.

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

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

[Stephen Frost]

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/12/17 2:22 PM, Stephen Frost wrote:
> > The point I was making above is that the only reason to not make such
> > changes is if they really are entirely arbitrary, but I don't think
> > we'd even be having this discussion if that was the case or that we'd
> > be split about the question.  We already moved forward with the real
> > change here- pg_xlog -> pg_wal, it really astounds me that we're having
> > to argue about what is primairly just clean-up from that change, at
> > least in my view.
> 
> I don't agree with the reasoning.  The change of the directory name was
> because some people erroneously delete the directory.  There is little
> to no risk that people accidentally delete built-in functions.  It was
> not agreed that because we rename the directory that all other uses of
> "xlog" have to be removed as well.  All those subsequent changes need to
> stand on their own.

The subsequent discussion about what to call the directory lead to a
pretty clear winner that a better name is "wal", which fits in pretty
nicely with things like "wal_level", "wal_sync_method", "wal_log_hints",
section 19.5 of our documentation.  Try finding 'xlog' or even
'transaction log' anywhere in our sample postgresql.conf, in fact.

Look at our docs too, we talk about WAL a *great* deal more than we talk
about 'xlog'.  Almost all utilization of 'xlog' that I see is due to
some function or program name which was derived from the directory name,
and half of those end up, confusingly, going back and forth between
"WAL" and "transaction log" (the description of pg_receivexlog is a
great example of this).

In the end, while I don't agree that they really need to, it seems
pretty clear to me that these changes can certainly stand on their own.
The only reason they were ever called 'xlog' was because of the
directory name and without that link, there's really no reason to keep
mis-calling these functions 'xlog' *except* this claim that we don't
want to break things, even though we're changing the directory name.

Thanks!

Stephen


signature.asc
Description: Digital signature