Обсуждение: backend type in log_line_prefix?
Attached is a demo patch that adds a placeholder %b for log_line_prefix (not in the default setting) that contains the backend type, the same that you see in pg_stat_activity and in the ps status. I would have found this occasionally useful when analyzing logs, especially if you have a lot of background workers active. Thoughts? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
On Thu, Feb 13, 2020 at 09:56:38AM +0100, Peter Eisentraut wrote: > Attached is a demo patch that adds a placeholder %b for log_line_prefix (not > in the default setting) that contains the backend type, the same that you > see in pg_stat_activity and in the ps status. I would have found this > occasionally useful when analyzing logs, especially if you have a lot of > background workers active. Thoughts? +1, I'd also have been happy to have it multiple times.
On 2020/02/13 18:14, Julien Rouhaud wrote: > On Thu, Feb 13, 2020 at 09:56:38AM +0100, Peter Eisentraut wrote: >> Attached is a demo patch that adds a placeholder %b for log_line_prefix (not >> in the default setting) that contains the backend type, the same that you >> see in pg_stat_activity and in the ps status. I would have found this >> occasionally useful when analyzing logs, especially if you have a lot of >> background workers active. Thoughts? If we do this, backend type should be also included in csvlog? Regarding the patch, postgresql.conf.sample needs to be updated. Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters
Hi, On 2020-02-13 09:56:38 +0100, Peter Eisentraut wrote: > Attached is a demo patch that adds a placeholder %b for log_line_prefix (not > in the default setting) that contains the backend type, the same that you > see in pg_stat_activity and in the ps status. I would have found this > occasionally useful when analyzing logs, especially if you have a lot of > background workers active. Thoughts? I wished for this several times. > @@ -342,7 +342,7 @@ AuxiliaryProcessMain(int argc, char *argv[]) > statmsg = "??? process"; > break; > } > - init_ps_display(statmsg, "", "", ""); > + init_ps_display((backend_type_str = statmsg), "", "", ""); > } But I'm decidedly not a fan of this. Greetings, Andres Freund
On 2020-02-13 09:56, Peter Eisentraut wrote: > Attached is a demo patch that adds a placeholder %b for log_line_prefix > (not in the default setting) that contains the backend type, the same > that you see in pg_stat_activity and in the ps status. I would have > found this occasionally useful when analyzing logs, especially if you > have a lot of background workers active. Thoughts? After positive initial feedback, here is a more ambitious patch set. In particular, I wanted to avoid having to specify the backend type (at least) twice, once for the ps display and once for this new facility. I have added a new global variable MyBackendType that uses the existing BackendType enum that was previously only used by the stats collector. Then the ps display, the stats collector, the log_line_prefix, and other places can just refer to this to know "who am I". (There are more places like that, for example in the autovacuum system, so patch 0004 in particular could be expanded in analogous ways.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
Updated patch set because of conflicts. On 2020-02-21 10:09, Peter Eisentraut wrote: > After positive initial feedback, here is a more ambitious patch set. In > particular, I wanted to avoid having to specify the backend type (at > least) twice, once for the ps display and once for this new facility. > > I have added a new global variable MyBackendType that uses the existing > BackendType enum that was previously only used by the stats collector. > Then the ps display, the stats collector, the log_line_prefix, and other > places can just refer to this to know "who am I". (There are more > places like that, for example in the autovacuum system, so patch 0004 in > particular could be expanded in analogous ways.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
Hello,
On Sat, Mar 7, 2020 at 8:38 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> Updated patch set because of conflicts.
>
Thank you for the patch. This feature is really helpful. Here are some
minor comments:
In v3-0001-Refactor-ps_status.c-API.patch,
- *
- * For a walsender, the ps display is set in the following form:
- *
- * postgres: walsender <user> <host> <activity>
This part is still valid, right?
+ init_ps_display(ps_data.data);
+ pfree(ps_data.data);
+
+ set_ps_display("initializing");
As per the existing behaviour, if update_process_title is true, we
display "authentication" as the initial string. On the other hand,
this patch, irrespective of the GUC variable, always displays
"initializing" as the initial string and In PerformAuthentication, it
sets the display as "authentication" Is this intended? Should we check
the GUC here as well?
In v3-0002-Unify-several-ways-to-tracking-backend-type.patch,
+ * If fixed_part is NULL, a default will be obtained from BackendType.
s/BackendType/MyBackendType?
In v3-0003-Add-backend-type-to-csvlog-and-optionally-log_lin.patch,
+ <entry>Backend process type</entry>
In other places you've written "backend type".
In v3-0004-Remove-am_syslogger-global-variable.patch,
+ * This is exported so that elog.c can call it when BackendType is B_LOGGER.
s/BackendType/MyBackendType?
Done some basic testing. Working as expected.
--
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com
On 2020-03-09 16:20, Kuntal Ghosh wrote:
> In v3-0001-Refactor-ps_status.c-API.patch,
>
> - *
> - * For a walsender, the ps display is set in the following form:
> - *
> - * postgres: walsender <user> <host> <activity>
> This part is still valid, right?
Sure but I figured this comment was in the context of the explanation of
how the old API was being abused, so it's no longer necessary.
> + init_ps_display(ps_data.data);
> + pfree(ps_data.data);
> +
> + set_ps_display("initializing");
> As per the existing behaviour, if update_process_title is true, we
> display "authentication" as the initial string. On the other hand,
> this patch, irrespective of the GUC variable, always displays
> "initializing" as the initial string and In PerformAuthentication, it
> sets the display as "authentication" Is this intended? Should we check
> the GUC here as well?
set_ps_display() checks update_process_title itself and does nothing if
it's off, so this should work okay.
> In v3-0002-Unify-several-ways-to-tracking-backend-type.patch,
> + * If fixed_part is NULL, a default will be obtained from BackendType.
> s/BackendType/MyBackendType?
yup
> In v3-0003-Add-backend-type-to-csvlog-and-optionally-log_lin.patch,
> + <entry>Backend process type</entry>
> In other places you've written "backend type".
ok changed
>
> In v3-0004-Remove-am_syslogger-global-variable.patch,
> + * This is exported so that elog.c can call it when BackendType is B_LOGGER.
> s/BackendType/MyBackendType?
ok
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Mar 10, 2020 at 4:41 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > On 2020-03-09 16:20, Kuntal Ghosh wrote: > > In v3-0002-Unify-several-ways-to-tracking-backend-type.patch, In pgstat_get_backend_desc(), the fallback "unknown process type" description shouldn't be required anymore. Other than that, it all looks good to me.
On Tue, Mar 10, 2020 at 9:11 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 2020-03-09 16:20, Kuntal Ghosh wrote: > > In v3-0001-Refactor-ps_status.c-API.patch, > > - * postgres: walsender <user> <host> <activity> > > This part is still valid, right? > Sure but I figured this comment was in the context of the explanation of > how the old API was being abused, so it's no longer necessary. > Makes sense. > set_ps_display() checks update_process_title itself and does nothing if > it's off, so this should work okay. Right. -- Thanks & Regards, Kuntal Ghosh EnterpriseDB: http://www.enterprisedb.com
I like these patches; the first two are nice cleanup. My only gripe is that pgstat_get_backend_desc() is not really a pgstat function; I think it should have a different name with a prototype in miscadmin.h (next to the enum's new location, which I would put someplace near the "pmod.h" comment rather than where you put it; perhaps just above the AuxProcType definition), and implementation probably in miscinit.c. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Feb 13, 2020 at 06:43:32PM +0900, Fujii Masao wrote: > If we do this, backend type should be also included in csvlog? +1, I've been missing that Note, this patch seems to correspond to: b025f32e0b Add leader_pid to pg_stat_activity I had mentioned privately to Julien missing this info in CSV log. Should leader_pid be exposed instead (or in addition)? Or backend_type be a positive number giving the leader's PID if it's a parallel worker, or a some special negative number like -BackendType to indicate a nonparallel worker. NULL for a B_BACKEND which is not a parallel worker. My hope is to answer to questions like these: . is query (ever? usually?) using parallel paths? . is query usefully using parallel paths? . what queries are my max_parallel_workers(_per_process) being used for ? . Are certain longrunning or frequently running queries which are using parallel paths using all max_parallel_workers and precluding other queries from using parallel query ? Or, are semi-short queries sometimes precluding longrunning queries from using parallelism, when the long queries would better benefit ? I think this patch alone wouldn't provide that, and there'd need to either be a line logged for each worker. Maybe it'd log full query+details (ugh), or just log "parallel worker of pid...". Or maybe there'd be a new column with which the leader would log nworkers (workers planned vs workers launched - I would *not* want to get this out of autoexplain). -- Justin
On Tue, Mar 10, 2020 at 02:01:42PM -0500, Justin Pryzby wrote:
> On Thu, Feb 13, 2020 at 06:43:32PM +0900, Fujii Masao wrote:
> > If we do this, backend type should be also included in csvlog?
>
> +1, I've been missing that
>
> Note, this patch seems to correspond to:
> b025f32e0b Add leader_pid to pg_stat_activity
>
> I had mentioned privately to Julien missing this info in CSV log.
>
> Should leader_pid be exposed instead (or in addition)? Or backend_type be a
I looked more closely and played with the patch.
Can I suggest:
$ git diff
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index 3a6f7f9456..56e0a1437e 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -2945,7 +2945,7 @@ write_csvlog(ErrorData *edata)
if (MyProcPid == PostmasterPid)
appendCSVLiteral(&buf, "postmaster");
else if (MyBackendType == B_BG_WORKER)
- appendCSVLiteral(&buf, MyBgworkerEntry->bgw_type);
+ appendCSVLiteral(&buf, MyBgworkerEntry->bgw_name);
else
appendCSVLiteral(&buf, pgstat_get_backend_desc(MyBackendType));
Then it logs the leader:
|2020-03-11 13:16:05.596 CDT,,,16289,,5e692ae3.3fa1,1,,2020-03-11 13:16:03 CDT,4/3,0,LOG,00000,"temporary file: path
""base/pgsql_tmp/pgsql_tmp16289.0"",size 4276224",,,,,,"explain analyze SELECT * FROM t a JOIN t b USING(i) WHERE i>999
GROUPBY 1;",,,"psql","parallel worker for PID 16210"
It'll be easy enough to extract the leader and join that ON leader=pid.
> I think this patch alone wouldn't provide that, and there'd need to either be a
> line logged for each worker. Maybe it'd log full query+details (ugh), or just
> log "parallel worker of pid...". Or maybe there'd be a new column with which
> the leader would log nworkers (workers planned vs workers launched - I would
> *not* want to get this out of autoexplain).
I'm still not sure how to do that, though.
I see I can get what's needed at DEBUG1:
|2020-03-11 13:50:58.304 CDT,,,16196,,5e692aa7.3f44,22,,2020-03-11 13:15:03 CDT,,0,DEBUG,00000,"registering background
worker""parallel worker for PID 16210""",,,,,,,,,"","postmaster"
But I don't think it's viable to run for very long with log_statement=all,
log_min_messages=DEBUG.
--
Justin
On 2020-03-11 19:53, Justin Pryzby wrote: > Can I suggest: > > $ git diff > diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c > index 3a6f7f9456..56e0a1437e 100644 > --- a/src/backend/utils/error/elog.c > +++ b/src/backend/utils/error/elog.c > @@ -2945,7 +2945,7 @@ write_csvlog(ErrorData *edata) > if (MyProcPid == PostmasterPid) > appendCSVLiteral(&buf, "postmaster"); > else if (MyBackendType == B_BG_WORKER) > - appendCSVLiteral(&buf, MyBgworkerEntry->bgw_type); > + appendCSVLiteral(&buf, MyBgworkerEntry->bgw_name); > else > appendCSVLiteral(&buf, pgstat_get_backend_desc(MyBackendType)); The difference is intentional. bgw_type is so that you can filter and group by type. The bgw_name could be totally different for each instance. Having the bgw name available somehow would perhaps also be useful, but then we should also do this in a consistent way for processes that are not background workers, such as regular client backends or wal senders or autovacuum workers. Doing it just for background workers would create inconsistencies that the introduction of bgw_type some time ago sought to eliminate. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-03-10 19:07, Alvaro Herrera wrote: > I like these patches; the first two are nice cleanup. > > My only gripe is that pgstat_get_backend_desc() is not really a pgstat > function; I think it should have a different name with a prototype in > miscadmin.h (next to the enum's new location, which I would put > someplace near the "pmod.h" comment rather than where you put it; > perhaps just above the AuxProcType definition), and implementation > probably in miscinit.c. I have committed the refactoring patches with adjustments along these lines. The patch with the log_line_prefix and csvlog enhancements is still under discussion. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Feb 21, 2020 at 10:09:38AM +0100, Peter Eisentraut wrote:
> From 75ac8ed0c47801712eb2aa300d9cb29767d2e121 Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut <peter@eisentraut.org>
> Date: Thu, 20 Feb 2020 18:16:39 +0100
> Subject: [PATCH v2 3/4] Add backend type to csvlog and optionally log_line_prefix
> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
> index c1128f89ec..206778b1c3 100644
> --- a/doc/src/sgml/config.sgml
> +++ b/doc/src/sgml/config.sgml
> @@ -6470,6 +6470,11 @@ <title>What to Log</title>
characters are copied straight to the log line. Some escapes are
only recognized by session processes, and will be treated as empty by
background processes such as the main server process. Status
...
<entry>Escape</entry>
<entry>Effect</entry>
<entry>Session only</entry>
> <entry>Application name</entry>
> <entry>yes</entry>
> </row>
> + <row>
> + <entry><literal>%b</literal></entry>
> + <entry>Backend process type</entry>
> + <entry>yes</entry>
=> should say "no", it's not blank for background processes:
> +
> + if (MyProcPid == PostmasterPid)
> + backend_type_str = "postmaster";
> + else if (MyBackendType == B_BG_WORKER)
> + backend_type_str = MyBgworkerEntry->bgw_type;
> + else
> + backend_type_str = pgstat_get_backend_desc(MyBackendType);
--
Justin
On Fri, Mar 13, 2020 at 10:22:52PM +0100, Peter Eisentraut wrote: > >Can I suggest: > > > >- appendCSVLiteral(&buf, MyBgworkerEntry->bgw_type); > >+ appendCSVLiteral(&buf, MyBgworkerEntry->bgw_name); > > The difference is intentional. bgw_type is so that you can filter and group > by type. The bgw_name could be totally different for each instance. I found 5373bc2a0867048bb78f93aede54ac1309b5e227 Your patch adds bgw_type, which is also in pg_stat_activity, so I agree it's good to allow include it log_line_prefix and CSV. I suggest the CSV/log should also have the leader_pid, corresponding to | b025f32e0b Add leader_pid to pg_stat_activity With the attached on top of your patch, CSV logs like: 2020-03-14 22:09:39.395 CDT,"pryzbyj","template1",17030,"[local]",5e6d9c69.4286,2,"idle",2020-03-14 22:09:29 CDT,3/23,0,LOG,00000,"statement:explain analyze SELECT COUNT(1), a.a FROM t a JOIN t b ON a.a=b.a GROUP BY 2;",,,,,,,,,"psql","clientbackend", 2020-03-14 22:09:43.094 CDT,,,17042,,5e6d9c73.4292,1,,2020-03-14 22:09:39 CDT,4/3,0,LOG,00000,"temporary file: path ""base/pgsql_tmp/pgsql_tmp17042.0"",size 4694016",,,,,,"explain analyze SELECT COUNT(1), a.a FROM t a JOIN t b ON a.a=b.aGROUP BY 2;",,,"psql","parallel worker",17030 2020-03-14 22:09:43.094 CDT,,,17043,,5e6d9c73.4293,1,,2020-03-14 22:09:39 CDT,5/3,0,LOG,00000,"temporary file: path ""base/pgsql_tmp/pgsql_tmp17043.0"",size 4694016",,,,,,"explain analyze SELECT COUNT(1), a.a FROM t a JOIN t b ON a.a=b.aGROUP BY 2;",,,"psql","parallel worker",17030 As for my question "what's using/trying/failing to use parallel workers", I was able to look into that by parsing "Workers Planned/Launched" from autoexplain. It's not a *good* way to do it, but I don't see how to do better and I don't see any way this patch can improve that. -- Justin
Вложения
On 2020-03-13 22:24, Peter Eisentraut wrote: > On 2020-03-10 19:07, Alvaro Herrera wrote: >> I like these patches; the first two are nice cleanup. >> >> My only gripe is that pgstat_get_backend_desc() is not really a pgstat >> function; I think it should have a different name with a prototype in >> miscadmin.h (next to the enum's new location, which I would put >> someplace near the "pmod.h" comment rather than where you put it; >> perhaps just above the AuxProcType definition), and implementation >> probably in miscinit.c. > > I have committed the refactoring patches with adjustments along these > lines. The patch with the log_line_prefix and csvlog enhancements is > still under discussion. I have committed that last one also, after some corrections. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-03-15 10:57, Justin Pryzby wrote: > I suggest the CSV/log should also have the leader_pid, corresponding to > | b025f32e0b Add leader_pid to pg_stat_activity I haven't followed those developments. It sounds interesting, but I suggest you start a new thread or continue in the thread that added leader_pid. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020/03/15 19:32, Peter Eisentraut wrote: > On 2020-03-13 22:24, Peter Eisentraut wrote: >> On 2020-03-10 19:07, Alvaro Herrera wrote: >>> I like these patches; the first two are nice cleanup. >>> >>> My only gripe is that pgstat_get_backend_desc() is not really a pgstat >>> function; I think it should have a different name with a prototype in >>> miscadmin.h (next to the enum's new location, which I would put >>> someplace near the "pmod.h" comment rather than where you put it; >>> perhaps just above the AuxProcType definition), and implementation >>> probably in miscinit.c. >> >> I have committed the refactoring patches with adjustments along these >> lines. The patch with the log_line_prefix and csvlog enhancements is >> still under discussion. > > I have committed that last one also, after some corrections. Thanks for adding this nice feature! I have one comment; You seem to need to update file-fdw.sgml so that pglog table in the doc should include backend_type column. Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters
> On 2020/03/15 19:32, Peter Eisentraut wrote: > > On 2020-03-13 22:24, Peter Eisentraut wrote: > >> On 2020-03-10 19:07, Alvaro Herrera wrote: > >>> I like these patches; the first two are nice cleanup. > >>> > >>> My only gripe is that pgstat_get_backend_desc() is not really a pgstat > >>> function; I think it should have a different name with a prototype in > >>> miscadmin.h (next to the enum's new location, which I would put > >>> someplace near the "pmod.h" comment rather than where you put it; > >>> perhaps just above the AuxProcType definition), and implementation > >>> probably in miscinit.c. > >> > >> I have committed the refactoring patches with adjustments along these > >> lines. The patch with the log_line_prefix and csvlog enhancements is > >> still under discussion. > > > > I have committed that last one also, after some corrections. Sorry for being late to this thread, but was wondering if anyone had taken a look at the Process Centralization patchset that I submitted to this CF: https://www.postgresql.org/message-id/CAMN686HgTVRJBAw6hqFE4Lj8bgPLQqfp1c-%2BWBGUtEmg6wPVhg%40mail.gmail.com There's quite a bit of that code that is in the same vein as the MyBackendType changes proposed/merged in this thread. I think we could reduce a large portion of redundant code (including the pgstat_get_backend_desc code) while also centralizing/standardizing process startup. A few useful features (outside of code reduction) include the ability to identify backends prior to their Main functions, cleaner control of SubPostmasterMain logic (including implicit handling of shmem timing considerations). If others think it's worthwhile, I will work on rebasing those changes on the changes proposed/merged in this thread (re: MyBackendType). Thanks, -- Mike Palmiotto https://crunchydata.com
On Sun, Mar 15, 2020 at 7:32 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>
>
> I have committed that last one also, after some corrections.
>
IMHO we should also update file_fdw documentation. See attached!
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Вложения
On Thu, Mar 19, 2020 at 01:37:17PM -0300, Fabrízio de Royes Mello wrote: > > On Sun, Mar 15, 2020 at 7:32 AM Peter Eisentraut < > peter.eisentraut@2ndquadrant.com> wrote: > > > > > > I have committed that last one also, after some corrections. > > > > IMHO we should also update file_fdw documentation. See attached! > > Regards, > > -- > Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ > PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento > diff --git a/doc/src/sgml/file-fdw.sgml b/doc/src/sgml/file-fdw.sgml > index 28b61c8f2d..ed028e4ec9 100644 > --- a/doc/src/sgml/file-fdw.sgml > +++ b/doc/src/sgml/file-fdw.sgml > @@ -261,7 +261,8 @@ CREATE FOREIGN TABLE pglog ( > query text, > query_pos integer, > location text, > - application_name text > + application_name text, > + backend_type text > ) SERVER pglog > OPTIONS ( filename '/home/josh/data/log/pglog.csv', format 'csv' ); > </programlisting> Patch applied to master, thanks. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Hello. At Mon, 23 Mar 2020 18:38:53 -0400, Bruce Momjian <bruce@momjian.us> wrote in > Patch applied to master, thanks. The patch (8e8a0becb3) named archiver process as just "archiver". On the other hand the discussion in the thread [1] was going to name the process as "WAL/wal archiver". As all other processes related to WAL are named as walreceiver, walsender, walwriter, wouldn't we name the process like "wal archiver"? [1]: https://www.postgresql.org/message-id/20200319195410.icib45bbgjwqb5zn@alap3.anarazel.de regards. -- Kyotaro Horiguchi NTT Open Source Software Center
On Fri, Mar 27, 2020 at 04:30:07PM +0900, Kyotaro Horiguchi wrote: > Hello. > > At Mon, 23 Mar 2020 18:38:53 -0400, Bruce Momjian <bruce@momjian.us> wrote in > > Patch applied to master, thanks. > > The patch (8e8a0becb3) named archiver process as just "archiver". On > the other hand the discussion in the thread [1] was going to name the > process as "WAL/wal archiver". As all other processes related to WAL > are named as walreceiver, walsender, walwriter, wouldn't we name the > process like "wal archiver"? > > [1]: https://www.postgresql.org/message-id/20200319195410.icib45bbgjwqb5zn@alap3.anarazel.de Agreed. I ended up moving "wal" as a separate word, since it looks cleaner; patch attached. Tools that look for the backend type in pg_stat_activity would need to be adjusted; it would be an incompatibility. Maybe changing it would cause too much disruption. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Вложения
On 2020-04-01 03:55, Bruce Momjian wrote: > Agreed. I ended up moving "wal" as a separate word, since it looks > cleaner; patch attached. Tools that look for the backend type in > pg_stat_activity would need to be adjusted; it would be an > incompatibility. Maybe changing it would cause too much disruption. Yeah, it's probably not worth the change for that reason. There is no confusion what the "archiver" is. Also, we have archive_mode, archive_command, etc. without a wal_ prefix. Let's leave it as is. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services