Thread: pgAdminIII and the LogFile - useless for debugging
pgAdminIII 1.2.0 PostgreSQL 8.0
I moved over from Linux to do some work with Pg on Windows. Windows
doesn't have a "tail" command unless you use cygwin tail it from there.
So, I was quite happy to see the Tools->Server Status->LogFile option in
pgAdminIII.
The first thing I noticed is that it doesn't "tail". The scroll bar
stays where it was an you move it manually. That's something I can live
with but I'd love to see it able to put the latest queries on top or
scroll the bar and allow you to scroll back to get into the history buffer.
Anyway, I turned my logging level to LOG and my log_statement to all so
I can see what is actually being SELECTED. This is a great way to debug
your web application in my experience. Imagine my disappointment when
the log file started filling up with this junk:
2005-03-01 17:39:04 LOG: statement: SELECT pg_file_length('C:/Program
Files/PostgreSQL/8.0/data/pg_log/postgresql-2005-03-01_173622.log') AS len
2005-03-01 17:39:04 LOG: statement: SELECT len FROM pg_file_stat($1) AS
s(len int8, c timestamp, a timestamp, m timestamp, i bool)
2005-03-01 17:39:04 CONTEXT: SQL function "pg_file_length" during inlining
...making it virtually completely useless.
PgAdmin needs to find another way to get the log file length besides a
SQL query to the database! I'm off to deal with cygwin now. :(
Is this the place to put in enhancement requests/bug notices?
Cordially,
Scott
hi scott! if you only need the tail command, you will probably find this package _very_ useful, and with it you probably will not need cygwin: http://unxutils.sourceforge.net/ hope this will help you with your work until you will be able to manage everything you need from within pgadmin. regards, M Scott Chapman wrote: > pgAdminIII 1.2.0 PostgreSQL 8.0 > > I moved over from Linux to do some work with Pg on Windows. Windows > doesn't have a "tail" command unless you use cygwin tail it from there. > > So, I was quite happy to see the Tools->Server Status->LogFile option in > pgAdminIII. > > The first thing I noticed is that it doesn't "tail". The scroll bar > stays where it was an you move it manually. That's something I can live > with but I'd love to see it able to put the latest queries on top or > scroll the bar and allow you to scroll back to get into the history buffer. > > Anyway, I turned my logging level to LOG and my log_statement to all so > I can see what is actually being SELECTED. This is a great way to debug > your web application in my experience. Imagine my disappointment when > the log file started filling up with this junk: > > 2005-03-01 17:39:04 LOG: statement: SELECT pg_file_length('C:/Program > Files/PostgreSQL/8.0/data/pg_log/postgresql-2005-03-01_173622.log') AS len > 2005-03-01 17:39:04 LOG: statement: SELECT len FROM pg_file_stat($1) AS > s(len int8, c timestamp, a timestamp, m timestamp, i bool) > 2005-03-01 17:39:04 CONTEXT: SQL function "pg_file_length" during inlining > > ...making it virtually completely useless. > > PgAdmin needs to find another way to get the log file length besides a > SQL query to the database! I'm off to deal with cygwin now. :( > > Is this the place to put in enhancement requests/bug notices?
> -----Original Message----- > From: pgadmin-support-owner@postgresql.org > [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of > Scott Chapman > Sent: 02 March 2005 01:58 > To: pgadmin-support@postgresql.org > Subject: [pgadmin-support] pgAdminIII and the LogFile - > useless for debugging > > > PgAdmin needs to find another way to get the log file length > besides a > SQL query to the database! I'm off to deal with cygwin now. :( Without rewriting the PostgreSQL communications protocol to allow non-SQL based interaction with the server, there is no way to do this. A workaround might be to add some easily distinguishable noise to the log viewer queries that we can then use to filter out those lines. > Is this the place to put in enhancement requests/bug notices? Yup, it's as good as any! Regards, Dave.
If you need unix commands on Win32 you can download "UnxUtils.zip": <http://unxutils.sourceforge.net/> Scott Chapman a écrit : > pgAdminIII 1.2.0 PostgreSQL 8.0 > > I moved over from Linux to do some work with Pg on Windows. Windows > doesn't have a "tail" command unless you use cygwin tail it from there. > > So, I was quite happy to see the Tools->Server Status->LogFile option > in pgAdminIII. > > The first thing I noticed is that it doesn't "tail". The scroll bar > stays where it was an you move it manually. That's something I can > live with but I'd love to see it able to put the latest queries on top > or scroll the bar and allow you to scroll back to get into the history > buffer. > > Anyway, I turned my logging level to LOG and my log_statement to all > so I can see what is actually being SELECTED. This is a great way to > debug your web application in my experience. Imagine my > disappointment when the log file started filling up with this junk: > > 2005-03-01 17:39:04 LOG: statement: SELECT pg_file_length('C:/Program > Files/PostgreSQL/8.0/data/pg_log/postgresql-2005-03-01_173622.log') AS > len > 2005-03-01 17:39:04 LOG: statement: SELECT len FROM pg_file_stat($1) > AS s(len int8, c timestamp, a timestamp, m timestamp, i bool) > 2005-03-01 17:39:04 CONTEXT: SQL function "pg_file_length" during > inlining > > ...making it virtually completely useless. > > PgAdmin needs to find another way to get the log file length besides a > SQL query to the database! I'm off to deal with cygwin now. :( > > Is this the place to put in enhancement requests/bug notices? > > Cordially, > Scott > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Jean-Marie Arsac AZIMUT http://www.azimut.fr M 06 11 05 88 23
Scott Chapman wrote:
> pgAdminIII 1.2.0 PostgreSQL 8.0
>
> I moved over from Linux to do some work with Pg on Windows. Windows
> doesn't have a "tail" command unless you use cygwin tail it from there.
>
> So, I was quite happy to see the Tools->Server Status->LogFile option in
> pgAdminIII.
>
> The first thing I noticed is that it doesn't "tail". The scroll bar
> stays where it was an you move it manually. That's something I can live
> with but I'd love to see it able to put the latest queries on top or
> scroll the bar and allow you to scroll back to get into the history buffer.
>
> Anyway, I turned my logging level to LOG and my log_statement to all so
> I can see what is actually being SELECTED. This is a great way to debug
> your web application in my experience. Imagine my disappointment when
> the log file started filling up with this junk:
>
> 2005-03-01 17:39:04 LOG: statement: SELECT pg_file_length('C:/Program
> Files/PostgreSQL/8.0/data/pg_log/postgresql-2005-03-01_173622.log') AS len
> 2005-03-01 17:39:04 LOG: statement: SELECT len FROM pg_file_stat($1) AS
> s(len int8, c timestamp, a timestamp, m timestamp, i bool)
> 2005-03-01 17:39:04 CONTEXT: SQL function "pg_file_length" during inlining
>
> ...making it virtually completely useless.
I'm struck by this myself, you can set the automatic refresh to 0 to get
the log ony on demand.
>
> PgAdmin needs to find another way to get the log file length besides a
> SQL query to the database!
No, the real trouble is that logfile isn't quite convenient for client
side debugging. If you know e.g. M$SQL's profiler, you'd agree that
there's nothing similar on pgsql. I'd like to see it, so please head
over to pgsql-hackers for that. There's currently a thread "logging as
inserts" active, which could be a basis for this.
Regards,
Andreas
>>PgAdmin needs to find another way to get the log file length >>besides a >>SQL query to the database! I'm off to deal with cygwin now. :( > > > Without rewriting the PostgreSQL communications protocol to allow > non-SQL based interaction with the server, there is no way to do this. > > A workaround might be to add some easily distinguishable noise to the > log viewer queries that we can then use to filter out those lines. Dave, 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. 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? 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. The end result of #2 or #3 is that you'd still have a majorly clutter'd logfile whether PgAdmin showed them or not. 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!) Scott
> -----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