Обсуждение: Should rename "startup process" to something else?
Hi,
Regards,
Robert and I wondered whether we would like to rename the startup
process. The reason for doing this is that the current name doesn't
make any sense, as in the stand-by mode replay loop as the main
loop, the startup process stays around.
I think a better name for the process may be “recovery” or “WAL_replay”
or maybe someone has a better idea. One can say that startup is a very
generic name, so in the future, it gives flexibility in terms of assigning
any sort of 'work’. But in standby mode, the name “startup” doesn’t
make sense.
Open for suggestions and thoughts.
Rushabh Lathia
On Mon, Nov 15, 2021 at 8:03 PM Rushabh Lathia <rushabh.lathia@gmail.com> wrote: > Robert and I wondered whether we would like to rename the startup > > process. The reason for doing this is that the current name doesn't > > make any sense, as in the stand-by mode replay loop as the main > > loop, the startup process stays around. The startup process main function looks to be to do some initialization required for recovery and do the recovery, exit if it is a crash recovery or stay there if it is a standby recovery. Apart from these I'm not sure it does any non-recovery tasks. Does the startup process have any relevance or work to do if the server state is DB_SHUTDOWNED i.e the server was shutdown properly? I think yes, although it doesn't enter the recovery/REDO loop, it does a bunch of other things like updating the control file, pre-allocating WAL files, updating shared memory state to allow other backends to write WAL and so on. By keeping this in mind, just renaming the startup process to "recovery" or some other doesn't look good IMO. Instead, we can live with it and be happy with the ps display update that we do in XLogFileRead. > I think a better name for the process may be “recovery” or “WAL_replay” > > or maybe someone has a better idea. One can say that startup is a very > > generic name, so in the future, it gives flexibility in terms of assigning > > any sort of 'work’. But in standby mode, the name “startup” doesn’t > > make sense. > > Open for suggestions and thoughts. If at all, we were to change the startup process to "recovery" or some other, it's not going to be a tiny change, we need to change the code with some user facing error message, docs, testsm which isn't good from code maintainability and especially the diff it creates with the back branches that we support. Others may have better thoughts. Regards, Bharath Rupireddy.
> 15 нояб. 2021 г., в 19:32, Rushabh Lathia <rushabh.lathia@gmail.com> написал(а): > > Open for suggestions and thoughts. How about walapplier ? Similar to walsender, walreciver.. Best regards, Andrey Borodin.
On Thu, Nov 18, 2021 at 6:06 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote: > > > > > 15 нояб. 2021 г., в 19:32, Rushabh Lathia <rushabh.lathia@gmail.com> написал(а): > > > > Open for suggestions and thoughts. > > > How about walapplier ? > Similar to walsender, walreciver.. > Or maybe walreplayer ? Regards, Amul
On Thu, Nov 18, 2021 at 5:34 AM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > The startup process main function looks to be to do some > initialization required for recovery and do the recovery, exit if it > is a crash recovery or stay there if it is a standby recovery. Apart > from these I'm not sure it does any non-recovery tasks. Does the > startup process have any relevance or work to do if the server state > is DB_SHUTDOWNED i.e the server was shutdown properly? I think yes, > although it doesn't enter the recovery/REDO loop, it does a bunch of > other things like updating the control file, pre-allocating WAL files, > updating shared memory state to allow other backends to write WAL and > so on. That's true, but those tasks are very brief. Nobody's going to get too confused by a "recovery" process that shows up for a few milliseconds when there's no recovery to be done. Having a "startup" process that sticks around forever on a standy, though, actually is confusing. -- Robert Haas EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes:
> That's true, but those tasks are very brief. Nobody's going to get too
> confused by a "recovery" process that shows up for a few milliseconds
> when there's no recovery to be done. Having a "startup" process that
> sticks around forever on a standy, though, actually is confusing.
Yeah, given current usage it would be better to call it the "recovery
process". However, I'm feeling dubious that it's worth the cost to
change. The "startup" name is embedded in a lot of places, I think,
and people are used to it. I fear changing it would create more
confusion than it removes.
regards, tom lane
On Thu, Nov 18, 2021 at 11:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Yeah, given current usage it would be better to call it the "recovery > process". However, I'm feeling dubious that it's worth the cost to > change. The "startup" name is embedded in a lot of places, I think, > and people are used to it. I fear changing it would create more > confusion than it removes. What sorts of places are you thinking about? As far as being used to it, I think hackers are, but regular users are very much not. And there are a lot more regular users than there are hackers, and it's harder to get them to pay attention, too. -- Robert Haas EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Nov 18, 2021 at 11:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, given current usage it would be better to call it the "recovery
>> process". However, I'm feeling dubious that it's worth the cost to
>> change. The "startup" name is embedded in a lot of places, I think,
>> and people are used to it. I fear changing it would create more
>> confusion than it removes.
> What sorts of places are you thinking about?
Aside from our own code, I imagine a lot of people have monitoring
scripts that know about it.
> As far as being used to it, I think hackers are, but regular users are
> very much not.
Being hackers ourselves, I'm not sure we're qualified to opine on
that. I cannot say that I've noticed any questions about it on
the mailing lists, though.
Personally I think making a glossary entry that explains what the
process does would be a better plan than renaming it.
regards, tom lane
On Tue, Nov 16, 2021 at 3:33 AM Rushabh Lathia <rushabh.lathia@gmail.com> wrote: > I think a better name for the process may be “recovery” +1
On Thu, Nov 18, 2021 at 12:24:14PM -0500, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Thu, Nov 18, 2021 at 11:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Yeah, given current usage it would be better to call it the "recovery > >> process". However, I'm feeling dubious that it's worth the cost to > >> change. The "startup" name is embedded in a lot of places, I think, > >> and people are used to it. I fear changing it would create more > >> confusion than it removes. > > > As far as being used to it, I think hackers are, but regular users are > > very much not. > > Being hackers ourselves, I'm not sure we're qualified to opine on > that. I cannot say that I've noticed any questions about it on > the mailing lists, though. A data point: I was recently confused when I observed the "startup" process running for a bit after restarting the instance (because connections were being rejected) I concluded that the shutdown was unclean, and started to blame the PGDG RPM's initscript [0]. Actually, the shutdown was clean, and the "startup" process was just slow doing $somethingelse (I imagine this will be less confusing in pg15 - 9ce346eabf). [0] I believe this is configured such that systemd could kill -9 the postmaster (but that's not what happened in this case). https://redmine.postgresql.org/issues/6855 If you rename "startup", I think "recovery" would be a bad choice, since it seems to imply that recovery/wal replay was necessary. > Personally I think making a glossary entry that explains what the > process does would be a better plan than renaming it. Since d3014fff4: https://www.postgresql.org/docs/devel/glossary.html#GLOSSARY-STARTUP-PROCESS -- Justin
Justin Pryzby <pryzby@telsasoft.com> writes: > On Thu, Nov 18, 2021 at 12:24:14PM -0500, Tom Lane wrote: >> Personally I think making a glossary entry that explains what the >> process does would be a better plan than renaming it. > Since d3014fff4: > https://www.postgresql.org/docs/devel/glossary.html#GLOSSARY-STARTUP-PROCESS Hm ... I might've found that, if it were in alphabetical order ... regards, tom lane
On Thu, Nov 18, 2021 at 12:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Being hackers ourselves, I'm not sure we're qualified to opine on > that. I cannot say that I've noticed any questions about it on > the mailing lists, though. What I've noticed when supporting EDB customer is that if, say, there's a problem with recovery, and they're trying to figure out which process is responsible, they have no intuition that the startup process is the likely culprit. They could, for example, notice whether the LSN that shows up in the ps status is advancing over time. Or, they could notice whether that process is doing a lot of I/O, or a lot of CPU. But since they have no notion that a startup process has anything to do with recovery, they don't make that connection. Now you can argue that I ought to be happy about that because, hey, it's job security. And you can also argue that even if the process had a better name, a lot of people wouldn't figure it out for one reason or another. However, my view is that we do well to make things more comprehensible when we can. -- Robert Haas EDB: http://www.enterprisedb.com
On 2021-Nov-18, Tom Lane wrote: > Justin Pryzby <pryzby@telsasoft.com> writes: > > On Thu, Nov 18, 2021 at 12:24:14PM -0500, Tom Lane wrote: > >> Personally I think making a glossary entry that explains what the > >> process does would be a better plan than renaming it. > > > Since d3014fff4: > > https://www.postgresql.org/docs/devel/glossary.html#GLOSSARY-STARTUP-PROCESS > > Hm ... I might've found that, if it were in alphabetical order ... Ugh, my mistake. If the consensus is not to rename, I'll move it to the right place. If we change the name, and I support the idea that we do, I think a good name would be "wal replay". I think "recovery" is not great precisely because in a standby there is likely no crash that we're recovering from. The word "replay" is at odds with the other names, which stand for the device that carries out the task at hand (checkpointer, bgwriter, wal sender/receiver); but the word "replayer" seems to be extremely uncommon and IMO looks strange. If you see a process that claims to be "wal replay", you know perfectly well what it is. The glossary entry reads: An auxiliary process that replays WAL during crash recovery and in a physical replica. (The name is historical: the startup process was named before replication was implemented; the name refers to its task as it relates to the server startup following a crash.) If we rename, we can drop more than half of the entry and replace it with "This process was previously known as the startup process". ... oh, I noticed another mistake: "WAL receiver" does not say "(process)", like all other process entries do. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> If we change the name, and I support the idea that we do, I think a
> good name would be "wal replay". I think "recovery" is not great
> precisely because in a standby there is likely no crash that we're
> recovering from.
Fair point.
> The word "replay" is at odds with the other names,
> which stand for the device that carries out the task at hand
> (checkpointer, bgwriter, wal sender/receiver); but the word "replayer"
> seems to be extremely uncommon and IMO looks strange. If you see a
> process that claims to be "wal replay", you know perfectly well what it
> is.
I'm less concerned about the "er" than about the fact that the name is
two words. People will immediately shorten it to just "replay", eg
as a part of names in the code, and I feel that that's confusing in
its own way. Maybe we could run the words together, on the precedent
of "walreceiver", but I never much liked that name either.
regards, tom lane
On 11/18/21, 12:24 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: >> If we change the name, and I support the idea that we do, I think a >> good name would be "wal replay". I think "recovery" is not great >> precisely because in a standby there is likely no crash that we're >> recovering from. > > Fair point. > >> The word "replay" is at odds with the other names, >> which stand for the device that carries out the task at hand >> (checkpointer, bgwriter, wal sender/receiver); but the word "replayer" >> seems to be extremely uncommon and IMO looks strange. If you see a >> process that claims to be "wal replay", you know perfectly well what it >> is. > > I'm less concerned about the "er" than about the fact that the name is > two words. People will immediately shorten it to just "replay", eg > as a part of names in the code, and I feel that that's confusing in > its own way. Maybe we could run the words together, on the precedent > of "walreceiver", but I never much liked that name either. +1 to something like "wal replay" or "wal apply." My view is that terms like "startup" and "recovery" indicate the goal of the process while "replay" and "apply" just explain what it does. This would be in line with the other processes (e.g., the WAL receiver receives WAL, the checkpointer checkpoints, and the archiver archives). I don't have any strong opinion about it being two words, but maybe I am just conditioned from seeing walreceiver, walsender, and walwriter so often. Nathan
On Fri, Nov 19, 2021 at 11:45:40PM +0000, Bossart, Nathan wrote: > +1 to something like "wal replay" or "wal apply." My view is that > terms like "startup" and "recovery" indicate the goal of the process > while "replay" and "apply" just explain what it does. This would be > in line with the other processes (e.g., the WAL receiver receives WAL, > the checkpointer checkpoints, and the archiver archives). I don't > have any strong opinion about it being two words, but maybe I am just > conditioned from seeing walreceiver, walsender, and walwriter so > often. If we want to play the card of consistency with the existing names, that would be "walreplayer", then. Jokes apart, "WAL replay" sounds fine to me :) I would be tempted to do more than that, though, bite the bullet and go as far as renaming walsender to "WAL sender", "walreceiver" to "WAL receiver", and "walwriter" to "WAL writer", even if that means potentially breaking scripts monitoring ps outputs. -- Michael
Вложения
On 11/18/21 15:22, Tom Lane wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: >> If we change the name, and I support the idea that we do, I think a >> good name would be "wal replay". I think "recovery" is not great >> precisely because in a standby there is likely no crash that we're >> recovering from. > Fair point. > >> The word "replay" is at odds with the other names, >> which stand for the device that carries out the task at hand >> (checkpointer, bgwriter, wal sender/receiver); but the word "replayer" >> seems to be extremely uncommon and IMO looks strange. If you see a >> process that claims to be "wal replay", you know perfectly well what it >> is. > I'm less concerned about the "er" than about the fact that the name is > two words. People will immediately shorten it to just "replay", eg > as a part of names in the code, and I feel that that's confusing in > its own way. Maybe we could run the words together, on the precedent > of "walreceiver", but I never much liked that name either. > > Maybe something along those lines but using a dash/hyphen would work: e.g. wal-replayer cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
On 2021-Nov-20, Andrew Dunstan wrote: > Maybe something along those lines but using a dash/hyphen would work: > e.g. wal-replayer Yeah, the idea of a dash occurred to me too. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "La grandeza es una experiencia transitoria. Nunca es consistente. Depende en gran parte de la imaginación humana creadora de mitos" (Irulan)
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2021-Nov-20, Andrew Dunstan wrote:
>> Maybe something along those lines but using a dash/hyphen would work:
>> e.g. wal-replayer
> Yeah, the idea of a dash occurred to me too.
Bad memories of uuid-ossp float up ... can we use underscore?
regards, tom lane
On 2021-Nov-23, Tom Lane wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > > On 2021-Nov-20, Andrew Dunstan wrote: > >> Maybe something along those lines but using a dash/hyphen would work: > >> e.g. wal-replayer > > > Yeah, the idea of a dash occurred to me too. > > Bad memories of uuid-ossp float up ... can we use underscore? I don't object to an underscore, but it looks a bit uglier to me. AFAIK the main problem with uuid-ossp was that it is used as an identifier, so it required quoting, which won't be the case with this process name. Anyway, as a second and separate point, should we rename the other WAL-related process names to use the same character? walreceiver -> wal_receiver / wal-receiver walsender -> wal_sender / wal-sender walwriter -> wal_writer / wal-writer. I assume we would *not* rename other existing processes that already have spaces in their names, such as "autovacuum launcher" to "autovacuum_launcher", as that would be a net loss IMO. Currently, the process list in an idle primary server looks like USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND alvherre 1091970 0.0 0.0 199608 22252 pts/0 S+ 12:22 0:00 /pgsql/install/master/bin/postmaster -p 55432 alvherre 1091983 0.0 0.0 199608 3644 ? Ss 12:22 0:00 \_ postgres: checkpointer alvherre 1091984 0.0 0.0 199608 5432 ? Ss 12:22 0:00 \_ postgres: background writer alvherre 1091986 0.0 0.0 199608 8956 ? Ss 12:22 0:00 \_ postgres: walwriter alvherre 1091987 0.0 0.0 200148 7988 ? Ss 12:22 0:00 \_ postgres: autovacuum launcher alvherre 1091988 0.0 0.0 54432 4156 ? Ss 12:22 0:00 \_ postgres: stats collector alvherre 1091989 0.0 0.0 200036 6416 ? Ss 12:22 0:00 \_ postgres: logical replication launcher I think this looks better: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND alvherre 1091970 0.0 0.0 199608 22252 pts/0 S+ 12:22 0:00 /pgsql/install/master/bin/postmaster -p 55432 alvherre 1091983 0.0 0.0 199608 3644 ? Ss 12:22 0:00 \_ postgres: checkpointer alvherre 1091984 0.0 0.0 199608 5432 ? Ss 12:22 0:00 \_ postgres: background writer alvherre 1091986 0.0 0.0 199608 8956 ? Ss 12:22 0:00 \_ postgres: wal-writer alvherre 1091987 0.0 0.0 200148 7988 ? Ss 12:22 0:00 \_ postgres: autovacuum launcher alvherre 1091988 0.0 0.0 54432 4156 ? Ss 12:22 0:00 \_ postgres: stats collector alvherre 1091989 0.0 0.0 200036 6416 ? Ss 12:22 0:00 \_ postgres: logical replication launcher -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2021-Nov-23, Tom Lane wrote:
>> Bad memories of uuid-ossp float up ... can we use underscore?
> I don't object to an underscore, but it looks a bit uglier to me.
> AFAIK the main problem with uuid-ossp was that it is used as an identifier, so
> it required quoting, which won't be the case with this process name.
Well, we can call the process whatever we want, but we will need to
derive identifiers from that name, so you can't just ignore the issue.
regards, tom lane
On Wed, Nov 24, 2021 at 1:54 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > I don't object to an underscore, but it looks a bit uglier to me. > AFAIK the main problem with uuid-ossp was that it is used as an identifier, so > it required quoting, which won't be the case with this process name. I agree, and for that reason I would prefer no separator, or a space. That's what we do with other processes, and I think it's fine. It's worth thinking too about the fact that we may want to rename functions, adjust comments, etc. Each of those things has their own conventions. For example consider StartupProcessMain(). If we decide to call this the WAL replay process, I suppose that is going to become WALReplayMain(). For sure it's not going to be come WAL-Replay-Main(). But what displays in the 'ps' status should look like what we do in other cases. -- Robert Haas EDB: http://www.enterprisedb.com