Thread: pgAdminIII and the LogFile - useless for debugging

pgAdminIII and the LogFile - useless for debugging

From
Scott Chapman
Date:
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


Re: pgAdminIII and the LogFile - useless for debugging

From
Miha Radej
Date:
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?


Re: pgAdminIII and the LogFile - useless for debugging

From
"Dave Page"
Date:

> -----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.


Re: pgAdminIII and the LogFile - useless for debugging

From
Jean-Marie Arsac
Date:
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



Re: pgAdminIII and the LogFile - useless for debugging

From
Andreas Pflug
Date:
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


Re: pgAdminIII and the LogFile - useless for debugging

From
Scott Chapman
Date:
>>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


Re: pgAdminIII and the LogFile - useless for debugging

From
"Dave Page"
Date:

> -----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