Re: fix log_min_duration_statement logic error
От | Bruce Momjian |
---|---|
Тема | Re: fix log_min_duration_statement logic error |
Дата | |
Msg-id | 200310050415.h954FZX11973@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: fix log_min_duration_statement logic error (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I think they fit pretty nicely on one line, and lot of folks want that > > information. I realize it looks like bloatware because it duplicates > > some existing functionality, but I think it is a combination of duration > > and statement output that can't be done easily separately. > > Sure it can. You're essentially arguing that DBAs are too dumb to match > up matching query and duration log outputs. I don't buy that. I think > they'll be analyzing their logs with little Perl scripts anyway, and > that consistency of log output format will be worth more to those > scripts than sometimes having related items all on one log line. Yes, I am arguing that we shouldn't make people jump through Perl hoops to get a statement/duration line in their log files. I think it is asked for enough that a nice printed line will help them. If we already have the parameter, why not make it easy. If they are using Perl, they can already use log_statement and log_duration to print only queries taking over a certain amount of time. > >> BTW, there's a separate set of problems that have yet to be addressed, > >> which is how any of these logging options apply for V3-protocol query > >> operations. The existing code only seems to work for the old-style > >> query path. > > > You mean how are they passed to the client? I assumed that would work > > for pre-V3 clients. > > No, I mean the functionality isn't in the extended-query code path at > all, and it's not immediately clear where to insert it (eg, which steps > of parse/bind/execute do what logging, or where you measure duration). I assume it would be all executor stuff, but I see what you mean that the perpare isn't going through the normal query path. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: