Re: pgAdminIII and the LogFile - useless for debugging

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: pgAdminIII and the LogFile - useless for debugging
Дата
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E472B8C4@ratbert.vale-housing.co.uk
обсуждение исходный текст
Ответ на pgAdminIII and the LogFile - useless for debugging  (Scott Chapman <chappie@mischko.com>)
Список pgadmin-support

> -----Original Message-----
> From: Scott Chapman [mailto:chappie@mischko.com]
> Sent: 03 March 2005 01:39
> To: Dave Page
> Cc: pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] pgAdminIII and the LogFile -
> useless for debugging
>
>
> I'd hope there's an easier way to do this than rewriting
> communications
> protocols.
>
> Kludge #1: Make the database send these particular log entries to the
> log with a different category (above) LOG so that you can
> have them NOT
> be logged at all unless you set logging to something up in
> the DEBUG range.

I'd bet that will never happen - there's simply no way that a patch to
detect and re-categorise different queries would be accepted into the
server. Don't forget, it's not just pgAdmin that might want to do things
like that - phpPgAdmin, EMS PostgreSQL Manager, PG Lightning Admin might
all decide they want to add a query to that list - where is the line
drawn?

> Kludge #2: If it's a local install, where Pg is running on the same
> server as pgAdmin, then you could use a file-system method to
> learn when
> the log file changes, bypassing Pg entirely.  You could also
> use a file
> system call to read the file.  Kludgy all around, huh?

Very - just being on the same system doesn't necessarily mean your user
account on the host has permission to read the logfile of course. In
addition, we don't necessarily know that we are running on the same
system. Either of those can be overcome by falling back to the current
behaviour of course.

> Kludge #3: If you added some noise to the log, it has to take care of
> all three lines that are showing up there. The filtration
> would need to
> be handled by PgAdmin because Pg doesn't have any way to do
> this filtration.

Yeah, well I've tidied things up there a little already this morning -
pgAdmin was formatting queries across multiple lines as if a user might
want to read and edit them - I've taken out the \n's. The filtering
itself should be quite easy, and I'll try to look into that.

> The end result of #2 or #3 is that you'd still have a majorly
> clutter'd
> logfile whether PgAdmin showed them or not.

Depends on your refresh settings. I tend to run with refresh rate set to
zero and then just manually refresh when the event I'm looking for has
happened. May not suit you of course - YMMV.

> The non-kludgy way to fix this that will meet the need the best is to
> have the database developers put in the kludge at their end or
> re-engineer the communications protocols (like that will happen soon!)

Err, yeah :-)

Regards, Dave


В списке pgadmin-support по дате отправления:

Предыдущее
От: Scott Chapman
Дата:
Сообщение: Re: pgAdminIII and the LogFile - useless for debugging
Следующее
От: "James Prichard"
Дата:
Сообщение: AGGREGATE SYNTAX MISSING IN REVERSE ENGINEERED SQL