| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com> |
| Subject: | Re: please update ps display for recovery checkpoint |
| Date: | 2021-06-10 01:32:30 |
| Message-ID: | YMFrrnJqLeVeLqeF@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 07, 2021 at 01:28:06PM -0400, Robert Haas wrote:
> On Mon, Jun 7, 2021 at 12:02 PM Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
>> I've seen a few functions cause lengthy startups, including
>> SyncDataDirectory() (for which I was grateful to see 61752afb),
>> StartupReorderBuffer(), and RemovePgTempFiles(). I like the idea of
>> adding additional information in the ps title, but I also think it is
>> worth exploring additional ways to improve on these O(n) startup
>> tasks.
+1. I also agree with doing something for the ps output of the
startup process when these are happening in crash recovery.
> See also the nearby thread entitled "when the startup process doesn't"
> which touches on this same issue.
Here is a link to the thread:
https://www.postgresql.org/message-id/CA+TgmoaHQrgDFOBwgY16XCoMtXxsrVGFB2jNCvb7-ubuEe1MGg@mail.gmail.com
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-06-10 01:35:16 | Re: please update ps display for recovery checkpoint |
| Previous Message | houzj.fnst@fujitsu.com | 2021-06-10 01:26:38 | RE: Parallel INSERT SELECT take 2 |