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 PROTEC
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
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
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 sugg
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 degree,
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 o
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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?
The operating system API we are using is spec'
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 runni
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 not gettext-enabled. I guess we'll ha
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: [PATCHE
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 c
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
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 over
> several lines.
Somehow I fail to
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]>,
> P
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
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 over
> > several
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 qu
[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 app
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
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 th
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
>
> > 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 maki
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
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
>
> 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 quer
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 w
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
---
Tom Lane wrote:
> 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
I like it:
LO
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 a
Bruce Momjian <[EMAIL PROTECTED]> writes:
>Sets a minimum statement execution time (in milliseconds)
>above which a statement will be logged. All SQL statements
>that run longer than the time specified will be logged together
> ! with their actual durat
> 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 o
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
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >Sets a minimum statement execution time (in milliseconds)
> >above which a statement will be logged. All SQL statements
> >that run longer than the time specified will be logged together
> > !
Tom Lane wrote:
> 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 diff
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 qu
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 qu
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
Peter,
Attached are pg_controldata, pgscripts and libpq spanish translations.
I will be asking for review from the rest of the spanish group so there
probably will be more updates as we get the style polished.
Please install. Thanks.
--
Alvaro Herrera ()
"El que vive para el futuro es un iluso
This patch hasn't been forgotten about?
Chris
Christopher Kings-Lynne wrote:
Hi,
This patch finishes off the work that I did with making view
definitions use pretty printing.
It does:
* Pretty check constraints
* Pretty index predicates
* Pretty rule definitions
* Uppercases PRIMARY KEY and UN
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Agreed. elog is the proper place, because then you guarantee that it is
> all on one line. Is that OK? Do we have elogs that we want over
> several lines? Is this something we can do at this stage in beta?
As to the latter: sure. We've already hacke
Alvaro Herrera writes:
> Attached are pg_controldata, pgscripts and libpq spanish translations.
Installed.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your friend
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
Neil Conway <[EMAIL PROTECTED]> writes:
> (BTW, is there a reason the docs consistently call them "B-tree
> indexes", not "B+-tree indexes"?)
The latter might be technically more correct, but most people are going
to think it's a typo. I think B-tree is fine for the purposes of our docs.
46 matches
Mail list logo
