Re: [PATCHES] psql italian translation

[Gaetano Mendola]

Peter Eisentraut wrote:

Fabrizio Mazzoni writes:


I just translated the psql.pot file into Italian language and tested it in 7.4beta3.


Installed.  But please check out psql --help and \? within psql and line
up the strings correctly.

I don't know if there is some problem but some messages are not
translated in psql. The thing is that these messages are not present in
the .pot file .. Anyway if you want to check you must check the SQL help
for the DROP command and you will see it for yourself.


Works here:

peter=# \help DROP TABLE
Comando: DROP TABLE
Descrizione: elimina una tabella
Sinstassi:
DROP TABLE nome [, ...] [ CASCADE | RESTRICT ]
Please see my post ( I choose the wron address) on hackers, there are 
some typos on the traslation.

Regards
Gaetano Mendola




---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [PATCHES] psql italian translation

[Peter Eisentraut]

Fabrizio Mazzoni writes:

> I just translated the psql.pot file into Italian language and tested it in 7.4beta3.

Installed.  But please check out psql --help and \? within psql and line
up the strings correctly.

> I don't know if there is some problem but some messages are not
> translated in psql. The thing is that these messages are not present in
> the .pot file .. Anyway if you want to check you must check the SQL help
> for the DROP command and you will see it for yourself.

Works here:

peter=# \help DROP TABLE
Comando: DROP TABLE
Descrizione: elimina una tabella
Sinstassi:
DROP TABLE nome [, ...] [ CASCADE | RESTRICT ]

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PATCHES] fix log_min_duration_statement logic error

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Are those lines sent to the elog as one write() or separate ones --- do
> > they always appear together in the log?
> 
> Currently they are sent in a single fprintf(stderr), which might or
> might not be good enough to ensure atomicity.  We could hack this
> to a direct write() if you don't mind depending on fileno(stderr),
> but I think that'd create some portability issues on non-Unix
> platforms.
> 
> If you're using syslog then I think all bets are off anyway.
> 
> > I had a new idea on output format.  Instead of converting newline to
> > "\n", and double-escaping backslashes, we add a tab after any newline,
> 
> That's a thought... seems less invasive than the backslashing.  Not sure
> how well it'll work for syslog output though.

OK, new version attached that puts a tab before any elog continuation
line in the server logs.  This will give us consistent multi-line server
log output.  It does not affect the client output, which I think is
correct.

Output looks like:

LOG:  duration: 4.138 ms  query: select *
from pg_language;
LOG:  duration: 7.560 ms  query: select * from pg_class;

Now, this does not address Tom's objection that you have can't use grep
anyway to pull lines from the server logs, but it is closer to usable
for scripts, and easier for people to read in the file.

The problem with doing statement and duration on separate lines is this:

LOG:  duration: 4.138 ms  
LOG:  query: select *
from pg_language;
LOG:  duration: 7.560 ms  
LOG:  query: select * from pg_class;

It isn't clear which duration goes with which line, even if they don't
intermingle.  If you output on separate lines, you would have to use
log_pid.  However, since people can use log_duration and log_statement
separately already anyway, I think this merged line is easier for casual
users.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/runtime.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.210
diff -c -c -r1.210 runtime.sgml
*** doc/src/sgml/runtime.sgml   3 Oct 2003 19:26:49 -   1.210
--- doc/src/sgml/runtime.sgml   6 Oct 2003 21:33:06 -
***
*** 1689,1704 
 
  
   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 duration.  Setting this to zero (the default)
!disables time-based logging.  For example, if you set it
!  to 250 then all SQL statements that run longer
!  than 250ms will be logged.  Enabling this
!  option can be useful in tracking down unoptimized queries in
!  your applications.
!  Only superusers can increase this or set it to zero if this option
!  is set to non-zero by the administrator.
  
 

--- 1689,1704 
 
  
   Sets a minimum statement execution time (in milliseconds)
!  for statement to be logged.  All SQL statements
!  that run in the time specified or longer will be logged with
!  their duration.  Setting this to zero will print
!  all queries and their durations.  Minus-one (the default)
!  disables this.  For example, if you set it to 
!  250 then all SQL statements that run 250ms 
!  or longer will be logged.  Enabling this option can be
!  useful in tracking down unoptimized queries in your applications.
!  Only superusers can increase this or set it to minus-one if this 
!  option is set by the administrator.
  
 

Index: src/backend/tcop/postgres.c
===
RCS file: /cvsroot/pgsql-server/src/backend/tcop/postgres.c,v
retrieving revision 1.370
diff -c -c -r1.370 postgres.c
*** src/backend/tcop/postgres.c 4 Oct 2003 02:47:04 -   1.370
--- src/backend/tcop/postgres.c 6 Oct 2003 21:33:11 -
***
*** 694,700 
 * because gettimeofday() wasn't called. Similarly,
 * log_statement_stats has to be captured once.
 */
!   if (save_log_duration || save_log_min_duration_statement > 0)
gettimeofday(&start_t, NULL);
  
if (save_log_statement_stats)
--- 694,700 
 * because gettimeofday() wasn't called. Similarly,
 * log_statement_stats has to be captured once.
 */
!   if (save_log_duration || save_log_min_duration_statement != -1)
gettimeofday(&start_t, NULL);
  
if (sav

[PATCHES] psql italian translation

[Fabrizio Mazzoni]

Resending because i did not attahc the file .. !! Sorry for the mistake...

Hello, 

I just translated the psql.pot file into Italian language and tested it in 7.4beta3. 
It seems to work just fine. The "it" language is not in the nls.mk so it must be 
added. I don't know if there is some problem but some messages are not translated in 
psql. The thing is that these messages are not present in the .pot file ..
Anyway if you want to check you must check the SQL help for the DROP command and you 
will see it for yourself.

Best Regards,

Fabrizio Mazzoni
Macron Srl
http://eteampoint.com



psql.pot.gz
Description: Binary data

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

[PATCHES] Bug in pg_restore memory handling

[Bruce Momjian]

I found a bug in the pg_restore code.  It shows up only using the tar
format, and only on Windows XP (not Win2000 or BSD/OS).  However, the
bug exists on all platforms that don't return zero'ed memory from
malloc, which is basically everyone.  We have gotten away with this
because malloc memory is usually zeroed by accident in pg_dump (I think
because it is an early malloc call, not recycled from a free.)

The bug seems to only affect the output displayed by pg_restore --- the
data seems to restore fine.  To test, try:

pg_dump -Ft test >/tmp/test.db
pg_dump /tmp/test.db

For a simple case, you should see displayed by pg_restore:

COPY supplier (sno, sname, city) FROM stdin;
1   Smith   London
2   Jones   Paris
3   Adams   Vienna
4   Blake   Roma
\.

But on XP with the bug I see:

COPY supplier (sno, sname, city) FROM stdin;
\.
copy supplier (sno, sname, city)  from '$$PATH$$/6.dat' ;

The code in pg_backup_tar.c::InitArchiveFmt_Tar does:

ctx = (lclContext *) malloc(sizeof(lclContext));
AH->formatData = (void *) ctx;
ctx->filePos = 0;

What it doesn't do is to set ctx->isSpecialScript to zero:

ctx->isSpecialScript = 0;

pg_backup_tar::_PrintTocData() checks ctx->isSpecialScript for non-zero,
and then uses the wrong code path on XP.  The code is supposed to use
the ctx->isSpecialScript code path only after the archive is closed. 
This is set to true in _CloseArchive().  ctx->isSpecialScript is used
only for tar, so that's why only tar has the bug.

A simple patch would be to just add the ctx->isSpecialScript = 0, but a
more reliable patch would be to do that, plus change a few malloc calls
to calloc for complex structures where the initialization isn't clear in
the code.

I would like to apply the attached patch to 7.3.X and 7.4.

Comments?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
Index: src/bin/pg_dump/pg_backup_custom.c
===
RCS file: /cvsroot/pgsql-server/src/bin/pg_dump/pg_backup_custom.c,v
retrieving revision 1.25
diff -c -c -r1.25 pg_backup_custom.c
*** src/bin/pg_dump/pg_backup_custom.c  4 Aug 2003 00:43:27 -   1.25
--- src/bin/pg_dump/pg_backup_custom.c  6 Oct 2003 18:00:40 -
***
*** 136,142 
/*
 * Set up some special context used in compressing data.
 */
!   ctx = (lclContext *) malloc(sizeof(lclContext));
if (ctx == NULL)
die_horribly(AH, modulename, "out of memory\n");
AH->formatData = (void *) ctx;
--- 136,142 
/*
 * Set up some special context used in compressing data.
 */
!   ctx = (lclContext *) calloc(1, sizeof(lclContext));
if (ctx == NULL)
die_horribly(AH, modulename, "out of memory\n");
AH->formatData = (void *) ctx;
***
*** 253,259 
  
if (ctx == NULL)
{
!   ctx = (lclTocEntry *) malloc(sizeof(lclTocEntry));
te->formatData = (void *) ctx;
}
  
--- 253,259 
  
if (ctx == NULL)
{
!   ctx = (lclTocEntry *) calloc(1, sizeof(lclTocEntry));
te->formatData = (void *) ctx;
}
  
Index: src/bin/pg_dump/pg_backup_files.c
===
RCS file: /cvsroot/pgsql-server/src/bin/pg_dump/pg_backup_files.c,v
retrieving revision 1.21
diff -c -c -r1.21 pg_backup_files.c
*** src/bin/pg_dump/pg_backup_files.c   25 Oct 2002 01:33:17 -  1.21
--- src/bin/pg_dump/pg_backup_files.c   6 Oct 2003 18:00:40 -
***
*** 101,107 
/*
 * Set up some special context used in compressing data.
 */
!   ctx = (lclContext *) malloc(sizeof(lclContext));
AH->formatData = (void *) ctx;
ctx->filePos = 0;
  
--- 101,107 
/*
 * Set up some special context used in compressing data.
 */
!   ctx = (lclContext *) calloc(1, sizeof(lclContext));
AH->formatData = (void *) ctx;
ctx->filePos = 0;
  
***
*** 167,173 
lclTocEntry *ctx;
charfn[K_STD_BUF_SIZE];
  
!   ctx = (lclTocEntry *) malloc(sizeof(lclTocEntry));
if (te->dataDumper)
{
  #ifdef HAVE_LIBZ
--- 167,173 
lclTocEntry *ctx;
charfn[K_STD_BUF_SIZE];
  
!   ctx = (lclTocEntry *) calloc(1, sizeof(lclTocEntry));
if (te->dataDumper)
{
  #ifdef HAVE_LIBZ
***
*** 206,212 
  
if (ctx == NULL)
{
!   ctx = (lclTocEntry *) malloc(sizeof(lclTocEntry));
te->formatDa

Re: [PATCHES] brazilian portuguese translations

[Peter Eisentraut]

Euler Taveira de Oliveira writes:

> The file contains updated translations for libpq, pg_dump, pg_controldata and 
> pg_resetxlog and new ones pgscripts and psql.

Installed.

> I put the files in my machine because I don't know if the list accept attachs of 
> 41kb.

It does, but web is fine, too.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [PATCHES] fix log_min_duration_statement logic error

[Bruce Momjian]

Tom Lane wrote:
> Alvaro Herrera Munoz <[EMAIL PROTECTED]> writes:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> I had a new idea on output format.  Instead of converting newline to
> >> "\n", and double-escaping backslashes, we add a tab after any newline,
> 
> > Not good.  Some syslogs will replace the literal tab with a ^I.
> 
> That seems okay.  We just want to make sure continuation lines are
> easily distinguishable.  (But leading spaces would be okay with me too.)

Agreed.  It is easy to strip off the tab to rebuild the original query
--- striping off 8 spaces seems less logical.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 8: explain analyze is your friend

[PATCHES] brazilian portuguese translations

[Euler Taveira de Oliveira]

Peter,

The file contains updated translations for libpq, pg_dump, pg_controldata and 
pg_resetxlog and new ones pgscripts and psql.

I put the files in my machine because I don't know if the list accept attachs of 41kb.


Please apply.

[EMAIL PROTECTED]:~/pgsql/traducoes/versao_0_4$ msgfmt -c -v libpq-pt_BR.po 
100 translated messages.
[EMAIL PROTECTED]:~/pgsql/traducoes/versao_0_4$ msgfmt -c -v pg_controldata-pt_BR.po 
39 translated messages.
[EMAIL PROTECTED]:~/pgsql/traducoes/versao_0_4$ msgfmt -c -v pg_dump-pt_BR.po   
391 translated messages.
[EMAIL PROTECTED]:~/pgsql/traducoes/versao_0_4$ msgfmt -c -v pg_resetxlog-pt_BR.po 
57 translated messages.
[EMAIL PROTECTED]:~/pgsql/traducoes/versao_0_4$ msgfmt -c -v pgscripts-pt_BR.po
112 translated messages.
[EMAIL PROTECTED]:~/pgsql/traducoes/versao_0_4$ msgfmt -c -v psql-pt_BR.po  
453 translated messages.

-- 
Euler Taveira de Oliveira
euler (at) ufgnet.ufg.br
Desenvolvedor Web e Administrador de Sistemas
UFGNet - Universidade Federal de Goiás

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PATCHES] fix log_min_duration_statement logic error

[Tom Lane]

Alvaro Herrera Munoz <[EMAIL PROTECTED]> writes:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I had a new idea on output format.  Instead of converting newline to
>> "\n", and double-escaping backslashes, we add a tab after any newline,

> Not good.  Some syslogs will replace the literal tab with a ^I.

That seems okay.  We just want to make sure continuation lines are
easily distinguishable.  (But leading spaces would be okay with me too.)

> How would it handle multiple fields?  Say
> LOG: blah blah
> DETAIL: something
> HINT: something else

> Will it be
> LOG: blah blah
> DETAIL: something else
> HINT: something else

No, one would hope no tab before DETAIL/HINT/etc.  The idea is to be
able to recognize when the contents of one of these entries spans lines.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [PATCHES] fix log_min_duration_statement logic error

[Alvaro Herrera Munoz]

On Mon, Oct 06, 2003 at 10:42:57AM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:

> > I had a new idea on output format.  Instead of converting newline to
> > "\n", and double-escaping backslashes, we add a tab after any newline,
> 
> That's a thought... seems less invasive than the backslashing.  Not sure
> how well it'll work for syslog output though.

Not good.  Some syslogs will replace the literal tab with a ^I.
Maybe it should be a bunch of spaces when using syslog.
It seems a good idea to me anyway.

How would it handle multiple fields?  Say
LOG: blah blah
DETAIL: something
HINT: something else

Will it be
LOG: blah blah
DETAIL: something else
HINT: something else
?

-- 
Alvaro Herrera (<[EMAIL PROTECTED]>)
"Find a bug in a program, and fix it, and the program will work today.
Show the program how to find and fix a bug, and the program
will work forever" (Oliver Silfridge)

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [PATCHES] fix log_min_duration_statement logic error

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are those lines sent to the elog as one write() or separate ones --- do
> they always appear together in the log?

Currently they are sent in a single fprintf(stderr), which might or
might not be good enough to ensure atomicity.  We could hack this
to a direct write() if you don't mind depending on fileno(stderr),
but I think that'd create some portability issues on non-Unix
platforms.

If you're using syslog then I think all bets are off anyway.

> I had a new idea on output format.  Instead of converting newline to
> "\n", and double-escaping backslashes, we add a tab after any newline,

That's a thought... seems less invasive than the backslashing.  Not sure
how well it'll work for syslog output though.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [PATCHES] fix log_min_duration_statement logic error

[Bruce Momjian]

Tom Lane wrote:
> 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 hacked the formatting of the log
> output quite a bit since 7.3.  Better to hit them with this too now,
> than spread the pain over multiple releases.
> 
> As to the former: the only thing that seems debatable to me is what to
> do about the layout of the new multi-part ereport() messages.  I would
> be inclined to go for one line per part, viz
>   ERROR: blah blah blah
>   DETAIL: blah blah\nblah blah
>   HINT: blah blah\nblah blah\nblah blah
> but perhaps someone would like to argue for somehow collapsing all this
> to one line?  If so, how exactly?

Are those lines sent to the elog as one write() or separate ones --- do
they always appear together in the log?

I had a new idea on output format.  Instead of converting newline to
"\n", and double-escaping backslashes, we add a tab after any newline,
so the output looks like:

LOG:  duration: 4.035 ms  query: select *
from pg_language;

This makes the logs look better, and it is easier for script to grab
queries.  Grep doesn't work as well, but I think that is OK.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster