That's not the issue. It complained because it wanted a pointer to the size.
The relevant lines in winbase.h files are:
BOOL WINAPI GetUserNameA (LPSTR,PDWORD);
#define GetUserName GetUserNameA
I am using Mingw.
cheers
andrew
- Original Message -
From: Bruce Momjian [EMAIL
Tom Lane writes:
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
Tom Lane writes:
I would prefer to see the log entries look like
LOG: query: select * from pg_class;
LOG: duration: nn.nnn msec
I'm not fond of the abbrevation msec or even msecs. The official
abbreviation is ms.
Btw., I was wondering, are we kidding ourselves when we display
Peter Eisentraut wrote:
Tom Lane writes:
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
Peter Eisentraut wrote:
Tom Lane writes:
I would prefer to see the log entries look like
LOG: query: select * from pg_class;
LOG: duration: nn.nnn msec
I'm not fond of the abbrevation msec or even msecs. The official
abbreviation is ms.
Yep. Someone suggested msec in
Bruce Momjian wrote:
Btw., I was wondering, are we kidding ourselves when we display
microsecond precision to the user? What accuracy do these measurements
have in respect to what they are actually supposed to measure?
Not sure. I think the microsecond stuff is accurate to some
Peter Eisentraut [EMAIL PROTECTED] writes:
When you're dealing with a large installation, these little Perl scripts
become difficult. I've just had to deal with a similar issue with a
popular MTA which spreads the relevant log information over several lines.
If you're generating 500 MB of log
Bruce Momjian [EMAIL PROTECTED] writes:
Peter, any problems with pid wrap-around? I am thinking we need to
prepend a wrap count on the front of the pid output for 7.5.
Why? And how would you know when the PIDs have wrapped anyway?
The OS already guarantees that no two concurrently running
On Sat, 4 Oct 2003, Tom Lane wrote:
Date: Sat, 04 Oct 2003 15:43:34 -0400
From: Tom Lane [EMAIL PROTECTED]
To: Bruce Momjian [EMAIL PROTECTED]
Cc: Peter Eisentraut [EMAIL PROTECTED], Neil Conway [EMAIL PROTECTED],
PostgreSQL Patches [EMAIL PROTECTED]
Subject: Re: [PATCHES] fix
Hello Peter,
Attached please find updated translations of the items
in the subject. psql is not fully translated yet, but
I submit whatever I have and will update the rest as
time permits.
$ msgfmt -c -v psql-ru.po
341 translated messages, 112 untranslated messages.
$ msgfmt -c -v pg_dump-ru.po
That was true already with log_statement and log_duration as separate
operations. People use log_pid to deal with it.
Sorry to jump in... the log_pid is NOT ENOUGH where you have more than
3 connections a day (witch is my case)
log_pid isn't enough, but log_pid + log_connections
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
When you're dealing with a large installation, these little Perl scripts
become difficult. I've just had to deal with a similar issue with a
popular MTA which spreads the relevant log information over several lines.
If you're
On Sun, 5 Oct 2003, Rod Taylor wrote:
Date: Sun, 05 Oct 2003 13:05:32 -0400
From: Rod Taylor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Tom Lane [EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED],
Peter Eisentraut [EMAIL PROTECTED], Neil Conway [EMAIL PROTECTED],
PostgreSQL
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
BTW, EXPLAIN ANALYZE puts out
Total runtime: 406.53 msec
Do you want to make an exception to the string freeze to change this
to ms?
I just realized, all the things that are sent as a query result instead of
an error or notice are
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
BTW, EXPLAIN ANALYZE puts out
Total runtime: 406.53 msec
Do you want to make an exception to the string freeze to change this
to ms?
I just realized, all the things that are sent as a query result instead of
[EMAIL PROTECTED] writes:
Also I'd love to see the log_query being settable per database...
AFAIK you can do that now.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
It is pretty easy to continue pulling lines after the 'duration' hit to
see the full query, perhap using awk, or even grep with a + arg. I just
don't see why we should make it harder for folks by splitting it
Bruce Momjian [EMAIL PROTECTED] writes:
I have not heard from you why we should make it harder (split across two
lines), except for consistency with log_statement and log_duration
outputs.
That is exactly my argument. I'll freely admit that it's not a strong
point, but I find the claim that
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have not heard from you why we should make it harder (split across two
lines), except for consistency with log_statement and log_duration
outputs.
That is exactly my argument. I'll freely admit that it's not a strong
point, but
I have not heard from you why we should make it harder (split across two
lines), except for consistency with log_statement and log_duration
outputs.
I think this is a perfectly good argument. Don't make writing the tools
to parse the log more difficult than necessary.
Rather than making
Rod Taylor wrote:
-- Start of PGP signed section.
I have not heard from you why we should make it harder (split across two
lines), except for consistency with log_statement and log_duration
outputs.
I think this is a perfectly good argument. Don't make writing the tools
to parse the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have not heard from you why we should make it harder (split across two
lines), except for consistency with log_statement and log_duration
outputs.
That is exactly my argument. I'll freely admit that it's not a strong
point, but
have also added code to convert end-of-line characters to \n and \r, and
doubles backslashes. It also makes log_statement print as one line, and
shows pg_stat_activity as one line. Without this fix, you get:
And how does it look with what was originally a fairly readable 30 or 40
line query?
Rod Taylor wrote:
-- Start of PGP signed section.
have also added code to convert end-of-line characters to \n and \r, and
doubles backslashes. It also makes log_statement print as one line, and
shows pg_stat_activity as one line. Without this fix, you get:
And how does it look with
Bruce Momjian [EMAIL PROTECTED] writes:
Another example:
LOG: duration: 4.228 ms; select *\nfrom pg_language;
Minor quibble: would it read better as
LOG: duration n.nnn ms: query
or
LOG: duration n.nnn ms for query
regards, tom lane
Bruce Momjian [EMAIL PROTECTED] writes:
It is hard to understand how a tool would grab the query from the above
log except to look for another TAG: entry and stop there.
That was pretty much the centerpiece of my complaint --- up to now it's
been tremendously difficult to parse the PG logs
Probably pretty long. I think the pg_stat_activity case really needs
the \n because if not the query breaks the table output format. Not
I was actually thinking exactly the opposite. pg_stat_activity viewed in
pgadmin GUI is going to format the table perfectly fine, but with
everthing on one
Serguei Mokhov writes:
Attached please find updated translations of the items
in the subject.
Installed.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Rod Taylor wrote:
-- Start of PGP signed section.
Probably pretty long. I think the pg_stat_activity case really needs
the \n because if not the query breaks the table output format. Not
I was actually thinking exactly the opposite. pg_stat_activity viewed in
pgadmin GUI is going to
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
BTW, EXPLAIN ANALYZE puts out
Total runtime: 406.53 msec
Do you want to make an exception to the string freeze to change this
to ms?
I just realized, all the things that are sent as a query result instead of
The problem with two lines is that another log message could get between
them. I agree milliseconds makes more sense for output.
That's not a huge problem. I've run our servers like that for ages, and
there's not really any time when a human can't tell what's going on.
You can also turn on PID
On Sun, 2003-10-05 at 19:58, Tom Lane wrote:
That's a fairly useless place to put it, though, since someone would
only think to look at sort_mem if they already had a clue. It should
be mentioned under bulk data load (in performance tips chapter)
Attached is a doc patch that does this. The
32 matches
Mail list logo
