Re: Tracing down buildfarm "postmaster does not shut down" failures
От | Jim Nasby |
---|---|
Тема | Re: Tracing down buildfarm "postmaster does not shut down" failures |
Дата | |
Msg-id | 56BAA357.3020300@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Tracing down buildfarm "postmaster does not shut down" failures (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Tracing down buildfarm "postmaster does not shut down" failures
|
Список | pgsql-hackers |
On 2/8/16 2:45 PM, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: >> Tom Lane wrote: >>> What I'd like to do to investigate this is put in a temporary HEAD-only >>> patch that makes ShutdownXLOG() and its subroutines much chattier about >>> how far they've gotten and what time it is, and also makes pg_ctl print >>> out the current time if it gives up waiting. > >> Seems like a reasonable place to start. I assume you'll be installing >> some debug-elog calls, enabled by default, and then once the problem is >> fixed, we'll change the default to disabled but keep the actual calls? > > I had in mind to just "git revert" the patch when we're done with it. > There might be some parts we want to keep (for instance, I'm thinking of > logging "postmaster is done" after we've unlinked the pidfile, which might > be useful permanently). But I plan to err on the side of noisiness for > the moment, rather than make something I think has long-term value. It's already difficult enough for DBAs to debug some performance issues, so getting rid of logging is a step backwards. I realize it's unlikely that you could run DEBUG2 in a prod environment, but we still shouldn't be reducing visibility. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: