From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: What are exactly bootstrap processes, auxiliary processes, standalone backends, normal backends(user sessions)? |
Date: | 2021-09-07 11:22:27 |
Message-ID: | CALj2ACUL4YL1mKoA8=pMgxzb1F_cWw2Gi0osX_-aeifHqk1n5A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 7, 2021 at 5:48 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2021-Aug-14, Justin Pryzby wrote:
>
> > I elaborated on your definition and added here.
> > https://commitfest.postgresql.org/34/3285/
>
> Thanks! This works for me. After looking at it, it seemed to me that
> listing the autovacuum launcher is perfectly adapted, so we might as
> well do it; and add verbiage about it to the autovacuum entry. (I was
> first adding a whole new glossary entry for it, but it seemed overkill.)
>
> I also ended up adding an entry for WAL sender -- seems to round things
> nicely.
>
> ... In doing so I noticed that the definition for startup process and
> WAL receiver is slightly wrong. WAL receiver only receives, it doesn't
> replay; it is always the startup process the one that replays. So I
> changed that too.
Thanks for the v2 patch, here are some comments on it:
1) How about
A set of background processes (<firstterm>autovacuum
launcher</firstterm> and <firstterm>autovacuum workers</firstterm>)
that routinely perform
instead of
A set of background processes that routinely perform
?
2) In what way we call autovacuum launcher an auxiliary process but
not autovacuum worker? And autovacuum isn't a background worker right?
Why can't we call it an auxiliary process?
+ (but not the autovacuum workers),
3) Isn't it "WAL sender" instead of "WAL senders"?
+ (but not the <glossterm linkend="glossary-wal-sender">WAL
senders</glossterm>),
4) replays WAL during replication? Isn't it "replays WAL during crash
recovery or in standby mode"
+ An auxiliary process that replays WAL during replication and
+ crash recovery.
5) Should we mention that WAL archiver too is optional similar to
Logger (process)? Also, let us rearrange the text a bit to be in sync.
+ An auxiliary process which (if enabled) saves copies of
+ <glossterm linkend="glossary-wal-file">WAL files</glossterm>
+ An auxiliary process which (if enabled)
writes information about database events into the current
6) Shouldn't we mention "<glossterm
linkend="glossary-auxiliary-proc">auxiliary process</glossterm>
instead of just plain "auxilary process"?
7) Shouldn't we mention "<glossterm
linkend="glossary-primary-server">primary</glossterm>"? instead of
"primary server"?
+ to receive WAL from the primary server for replay by the
8) I agree to not call walsender an auxiliary process because it is
type of a <glossterm linkend="glossary-backend">backend</glossterm>
process that understands replication commands only. Instead of saying
"A process that runs..."
why can't we mention that in the description?
+ A process that runs on a server that streams WAL over a
+ network. The receiving end can be a
+ <glossterm linkend="glossary-wal-receiver">WAL receiver</glossterm>
Regards,
Bharath Rupireddy.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Luzanov | 2021-09-07 11:28:38 | Re: psql: \dl+ to list large objects privileges |
Previous Message | Peter Eisentraut | 2021-09-07 11:17:40 | Re: UNIQUE null treatment option |