Re: Checkpoint logging, revised patch
От | Tom Lane |
---|---|
Тема | Re: Checkpoint logging, revised patch |
Дата | |
Msg-id | 11400.1183231204@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Checkpoint logging, revised patch (Heikki Linnakangas <heikki@enterprisedb.com>) |
Список | pgsql-patches |
Heikki Linnakangas <heikki@enterprisedb.com> writes: > Greg Smith wrote: >> My original patch converted the buffers written to MB. > I don't think we currently use MB in any other log messages. If we go > down that route, we need to consider switching to MB everywhere. I left this as submitted by Heikki, mainly because the percentage-of- shared-buffers bit seemed useful to me and it would make less sense IMHO if attached to a number of megabytes instead of a number of buffers. But it's a judgment call for sure. Any other opinions out there? >> 1) Log every time a new WAL file was created, which ties into the recent >> discussion here that being a possible performance issue. > This could be useful. Done; I put in two DEBUG2 messages, one at start and one at completion of the file-creation. >> 2) Add a lower-level DEBUG statement when autovaccum was finished, > Did you check out log_autovacuum? Doesn't it do what you need? I concur that log_autovacuum seems to cover this already. >> 3) I fixed a line in postmaster.c so it formatted fork PIDsthe same way >> most other log statements do; most statements report it as (PID %d) and >> the difference in this form seemed undesirable > Hmm. Since it's DEBUG2 I don't care much either way. The changed message > looks inconsistent to me, since socket is printed differently. No strong opinion, but I left it as-is for the moment in case Alvaro is about to commit something in postmaster.c (I suspect the double-shutdown business is a bug in there). Don't want to cause merge problems for him just for cosmetic message cleanup. regards, tom lane
В списке pgsql-patches по дате отправления: