snprintf() argument reordering not working under Windows in 8.1

Nicolai Tufar wrote:

Greetings,

Last April we have made some changes to src/ports/snprintf.c so that it
would support argument reordering like %2$s, %1$d and such on
platforms where original snprintf() does not support it, like Windows,
HP-UX or NetBSD.

Sure, I remember. So glad you returned at this time. I found a design
limitation in that file yesterday. It can not output more then 4096
characters, and there are some cases with NUMERIC that try to output
more than that. For example:

SELECT pow(10::numeric, 10000) + 1;

should show a '1' at the end of the number, but with the existing code
you will just see 4095 0's and no more.

I am attaching the new snprintf.c and the patch itself for your review.
The change is to pass 'stream' down into the routines and output to the
FILE* right from inside the routine, rather than using a string. This
fixes the problem.

I am also thinking of modifying the code so if we are using snprintf.c
only because we need positional parameter control, we check for '$' in
the string and only use snprintf.c in those cases.

NLS messages of some languages, like Turkish, rely heavily on argument
reordering because of the language structure. In 8.1 Turkish messages
in Windows version are all broken because argument reordering is not there.

Really? I have not heard any report of that but this is new code in 8.1.

I examined commit logs and came to conclusion that src/port/snprintf.c
is not included in server when compiling under Windows because of change
to src/port/Makefile made in revision 1.28 by Bruce Momjian. See here:

http://developer.postgresql.org/cvsweb.cgi/pgsql/src/port/Makefile

Comment to the commit says:
`No server version of snprintf needed, so remove Makefile rule.'
In fact I think we need snprintf in server because NLS messages are
printed by the server.

Actually, that changes means that there was nothing backend-specific in
snprintf.c so we don't need a _special_ version for the backend. The
real change not to use snprintf.c on Win32 is in configure.in with this
comment:

# Force use of our snprintf if system's doesn't do arg control
# This feature is used by NLS
if test "$enable_nls" = yes &&
test $pgac_need_repl_snprintf = no &&
# On Win32, libintl replaces snprintf() with its own version that
# understands arg control, so we don't need our own. In fact, it
# also uses macros that conflict with ours, so we _can't_ use
# our own.
test "$PORTNAME" != "win32"; then
PGAC_FUNC_PRINTF_ARG_CONTROL
if test $pgac_cv_printf_arg_control != yes ; then
pgac_need_repl_snprintf=yes
fi
fi

Here is the commit:

revision 1.409
date: 2005/05/05 19:15:54; author: momjian; state: Exp; lines: +8 -2
On Win32, libintl replaces snprintf() with its own version that
understands arg control, so we don't need our own. In fact, it
also uses macros that conflict with ours, so we _can't_ use
our own.

So, I think it was Magnus who said that Win32 didn' need and couldn't
use our snprintf. Magnus, any ideas?

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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am also thinking of modifying the code so if we are using snprintf.c
only because we need positional parameter control, we check for '$' in
the string and only use snprintf.c in those cases.

What's the point? If the code is in there we may as well use it.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am also thinking of modifying the code so if we are using snprintf.c
only because we need positional parameter control, we check for '$' in
the string and only use snprintf.c in those cases.

What's the point? If the code is in there we may as well use it.

I was thinking it might avoid us hitting other bugs in there, but that
is pessimistic, of course. I will hold off on that idea.

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

Greetings,

I thought it will be as simple as changing Makefile, the issue seem to be
much more complicated. Unfortunately I have no PostgreSQL building
environment handy and will not be able to look at it until the end of next
week because I am moving my house :( But since this issue waited for so
long it may wait a week more.

2005/12/3, Bruce Momjian <pgman@candle.pha.pa.us>:

Sure, I remember. So glad you returned at this time. I found a design
limitation in that file yesterday. It can not output more then 4096
characters, and there are some cases with NUMERIC that try to output
more than that. For example:

SELECT pow(10::numeric, 10000) + 1;

should show a '1' at the end of the number, but with the existing code
you will just see 4095 0's and no more.

I am attaching the new snprintf.c and the patch itself for your review.
The change is to pass 'stream' down into the routines and output to the
FILE* right from inside the routine, rather than using a string. This
fixes the problem.

Your patch increase buffers from 4095 to 8192. Sounds good to me.

I am also thinking of modifying the code so if we are using snprintf.c
only because we need positional parameter control, we check for '$' in
the string and only use snprintf.c in those cases.

I too, was thinking of it at the beginning but decided that the code would
get even more complicated than it was at the moment and was afraid that
core team would not accept my patch. :)

NLS messages of some languages, like Turkish, rely heavily on argument
reordering because of the language structure. In 8.1 Turkish messages
in Windows version are all broken because argument reordering is not there.

Really? I have not heard any report of that but this is new code in 8.1.

Windows installer does not set lc_messages configuration variable
correctly in postgresql.conf file. It is a known issue and will be solved
in next version. Meanwhile user needs to open postgresql.conf file
and change

lc_messages = 'Turkish_Turkey.28599'
to
lc_messages = 'tr_TR.UTF-8'

manually. Apparently nobody cared to do it and Devrim never ever touches
Windows. The problem is there, I am definitely positive about it, here are
two lines from log file:

2005-11-20 12:36:37 HATA: "$s" yerinde $s 1 karakterinde
2005-12-03 19:14:27 LOG: "$s" veritabanın transaction ID warp limiti $u

Actually, that changes means that there was nothing backend-specific in
snprintf.c so we don't need a _special_ version for the backend. The
real change not to use snprintf.c on Win32 is in configure.in with this
comment:

# Force use of our snprintf if system's doesn't do arg control
# This feature is used by NLS
if test "$enable_nls" = yes &&
test $pgac_need_repl_snprintf = no &&
# On Win32, libintl replaces snprintf() with its own version that
# understands arg control, so we don't need our own. In fact, it
# also uses macros that conflict with ours, so we _can't_ use
# our own.
test "$PORTNAME" != "win32"; then
PGAC_FUNC_PRINTF_ARG_CONTROL
if test $pgac_cv_printf_arg_control != yes ; then
pgac_need_repl_snprintf=yes
fi
fi

Here is the commit:

revision 1.409
date: 2005/05/05 19:15:54; author: momjian; state: Exp; lines: +8 -2
On Win32, libintl replaces snprintf() with its own version that
understands arg control, so we don't need our own. In fact, it
also uses macros that conflict with ours, so we _can't_ use
our own.

I don't have MinGW build environment on my computer at the moment
and will not be able to install it until the end of next week but log messages
above were produced by PostgreSQL installed with 8.1.0-2 Windows installer
downloaded from postgresql.org. Since Turkish messages are printed
I suppose it was compiled with $enable_nls = yes

Thank you for your attention,
Regards,
Nicolai Tufar

Nicolai Tufar wrote:

Greetings,

I thought it will be as simple as changing Makefile, the issue seem to be
much more complicated. Unfortunately I have no PostgreSQL building
environment handy and will not be able to look at it until the end of next
week because I am moving my house :( But since this issue waited for so
long it may wait a week more.

Agreed. The problem is actually worse than I described --- see below.

2005/12/3, Bruce Momjian <pgman@candle.pha.pa.us>:

Sure, I remember. So glad you returned at this time. I found a design
limitation in that file yesterday. It can not output more then 4096
characters, and there are some cases with NUMERIC that try to output
more than that. For example:

SELECT pow(10::numeric, 10000) + 1;

should show a '1' at the end of the number, but with the existing code
you will just see 4095 0's and no more.

I am attaching the new snprintf.c and the patch itself for your review.
The change is to pass 'stream' down into the routines and output to the
FILE* right from inside the routine, rather than using a string. This
fixes the problem.

Your patch increase buffers from 4095 to 8192. Sounds good to me.

Well, that fixed-size buffer is now used only for sprintf(). The others
use the specified length (for snprintf()) or output directly to the
FILE* stream.

I am also thinking of modifying the code so if we are using snprintf.c
only because we need positional parameter control, we check for '$' in
the string and only use snprintf.c in those cases.

I too, was thinking of it at the beginning but decided that the code would
get even more complicated than it was at the moment and was afraid that
core team would not accept my patch. :)

Seems Tom didn't like that and no one else has commented.

NLS messages of some languages, like Turkish, rely heavily on argument
reordering because of the language structure. In 8.1 Turkish messages
in Windows version are all broken because argument reordering is not there.

Really? I have not heard any report of that but this is new code in 8.1.

Windows installer does not set lc_messages configuration variable
correctly in postgresql.conf file. It is a known issue and will be solved
in next version. Meanwhile user needs to open postgresql.conf file
and change

lc_messages = 'Turkish_Turkey.28599'
to
lc_messages = 'tr_TR.UTF-8'

manually. Apparently nobody cared to do it and Devrim never ever touches
Windows. The problem is there, I am definitely positive about it, here are
two lines from log file:

2005-11-20 12:36:37 HATA: "$s" yerinde $s 1 karakterinde
2005-12-03 19:14:27 LOG: "$s" veritaban?n transaction ID warp limiti $u

OK.

Actually, that changes means that there was nothing backend-specific in
snprintf.c so we don't need a _special_ version for the backend. The
real change not to use snprintf.c on Win32 is in configure.in with this
comment:

# Force use of our snprintf if system's doesn't do arg control
# This feature is used by NLS
if test "$enable_nls" = yes &&
test $pgac_need_repl_snprintf = no &&
# On Win32, libintl replaces snprintf() with its own version that
# understands arg control, so we don't need our own. In fact, it
# also uses macros that conflict with ours, so we _can't_ use
# our own.
test "$PORTNAME" != "win32"; then
PGAC_FUNC_PRINTF_ARG_CONTROL
if test $pgac_cv_printf_arg_control != yes ; then
pgac_need_repl_snprintf=yes
fi
fi

Here is the commit:

revision 1.409
date: 2005/05/05 19:15:54; author: momjian; state: Exp; lines: +8 -2
On Win32, libintl replaces snprintf() with its own version that
understands arg control, so we don't need our own. In fact, it
also uses macros that conflict with ours, so we _can't_ use
our own.

I don't have MinGW build environment on my computer at the moment
and will not be able to install it until the end of next week but log messages
above were produced by PostgreSQL installed with 8.1.0-2 Windows installer
downloaded from postgresql.org. Since Turkish messages are printed
I suppose it was compiled with $enable_nls = yes

OK, here is what happened. In March 2005, we got reports of compile
problems on Win32 using NLS:

http://archives.postgresql.org/pgsql-hackers/2005-03/msg00710.php

(See the quoted text under the posted text as well.) Basically,
libintl.h on Win32 replaces *printf calls with its own versions, and
does it using macros, _just_ like we do. This of course causes
conflicts and the system fails to compile. The _fix_ was to disable
port/*printf on Win32 when using NLS because NLS wants to use its own
*printf. I _assumed_ that libintl.h did this so it could use its own
routines that understood %$, but never verified that. It didn't seem we
had any choice to fix this, and got no problem reports about %$ not
working until yours.

After over a month with no solution I added the code as you see it now:

http://archives.postgresql.org/pgsql-hackers-win32/2005-05/msg00011.php

Oh, and it was Andrew Dunstan who worked on this, not Magnus. (Sorry
Magnus, Hello Andrew.)

Anyway, I think the big question is, was the pginstaller built with a
libintl that replaces *printf, and is it an *printf that doesn't
understand positional parameters, and so, how can we fix it.

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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

(See the quoted text under the posted text as well.) Basically,
libintl.h on Win32 replaces *printf calls with its own versions, and
does it using macros, _just_ like we do. This of course causes
conflicts and the system fails to compile. The _fix_ was to disable
port/*printf on Win32 when using NLS because NLS wants to use its own
*printf. I _assumed_ that libintl.h did this so it could use its own
routines that understood %$, but never verified that.

Oops ... [ insert standard cliche about assumptions ]

It might be interesting to find out why libintl is replacing these
functions if not to support arg reordering, but I suppose the bottom
line will just be that Microsoft is as brain dead as usual :-(

Anyway, I think the big question is, was the pginstaller built with a
libintl that replaces *printf, and is it an *printf that doesn't
understand positional parameters, and so, how can we fix it.

Would it work to modify c.h so that it #include's libintl.h, then #undefs
these macros, then #includes port.h to define 'em the way we want?
Some or all of this might need to be #ifdef WIN32, but that seems like
a reasonably noninvasive solution if it can work.

regards, tom lane

Bruce Momjian wrote:

OK, here is what happened. In March 2005, we got reports of compile
problems on Win32 using NLS:

http://archives.postgresql.org/pgsql-hackers/2005-03/msg00710.php

(See the quoted text under the posted text as well.) Basically,
libintl.h on Win32 replaces *printf calls with its own versions, and
does it using macros, _just_ like we do. This of course causes
conflicts and the system fails to compile. The _fix_ was to disable
port/*printf on Win32 when using NLS because NLS wants to use its own
*printf. I _assumed_ that libintl.h did this so it could use its own
routines that understood %$, but never verified that. It didn't seem we
had any choice to fix this, and got no problem reports about %$ not
working until yours.

After over a month with no solution I added the code as you see it now:

http://archives.postgresql.org/pgsql-hackers-win32/2005-05/msg00011.php

Oh, and it was Andrew Dunstan who worked on this, not Magnus. (Sorry
Magnus, Hello Andrew.)

Anyway, I think the big question is, was the pginstaller built with a
libintl that replaces *printf, and is it an *printf that doesn't
understand positional parameters, and so, how can we fix it.

Well , I diagnosed the problem - you're on your own as far as the
"solution" goes ;-)

On thing that seems clear to me is that we need a way of testing NLS
support.

Tom said:

Would it work to modify c.h so that it #include's libintl.h, then #undefs
these macros, then #includes port.h to define 'em the way we want?
Some or all of this might need to be #ifdef WIN32, but that seems like
a reasonably noninvasive solution if it can work.

IIRC last time I tried this it didn't work too well ;-( I will have
another go. I think it's the best way to go.

cheers

andrew

Andrew Dunstan wrote:

Tom said:

Would it work to modify c.h so that it #include's libintl.h, then
#undefs
these macros, then #includes port.h to define 'em the way we want?
Some or all of this might need to be #ifdef WIN32, but that seems like
a reasonably noninvasive solution if it can work.

IIRC last time I tried this it didn't work too well ;-( I will have
another go. I think it's the best way to go.

progress so far: I undid the config changes Bruce had made and undefined
printf, fprintf, sprintf, snprintf and vsnprintf after the include of
libintl.h in include/c.h. Then to clean up some warnings I undefined
vsnprintf and snprintf in interfaces/libpq/win32.h before their
redefinition.

That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that - windows
experts, please advise.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that - windows
experts, please advise.

Plan A would be to make libpq export pg_snprintf and friends, Plan B
would be to give ecpg its own copy of snprintf.o. Plan A is probably
better since you're going to hit the same issue no doubt in all of the
src/bin programs.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that - windows
experts, please advise.

Plan A would be to make libpq export pg_snprintf and friends, Plan B
would be to give ecpg its own copy of snprintf.o. Plan A is probably
better since you're going to hit the same issue no doubt in all of the
src/bin programs.

I am confused why we would need either of these. All apps use
libpgport, and that pg_*printf should be in that library. The original
work Andrew did has problems particularly with ecpg, but why does ecpg
cause problems? Doesn't it link in pgport?

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

Bruce Momjian wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that - windows
experts, please advise.

Plan A would be to make libpq export pg_snprintf and friends, Plan B
would be to give ecpg its own copy of snprintf.o. Plan A is probably
better since you're going to hit the same issue no doubt in all of the
src/bin programs.

I am confused why we would need either of these. All apps use
libpgport, and that pg_*printf should be in that library. The original
work Andrew did has problems particularly with ecpg, but why does ecpg
cause problems? Doesn't it link in pgport?

libpgtypes doesn't link with either libpgport or libpq.

What I have done to get a working build in addition to the previous
report is to undef snprintf and sprintf in
interfaces/pgtypeslib/extern.h (instead of creating an additional link
burden), and to add entries for pg_snprintf, pg_sprintf and pg_fprintf
to interfaces/libpq/exports.txt. That let me get a clean compile and
regression run. The diff against 8.1 is attached for comment.

I suspect we should probably add all the pg_*printf functions to
exports.txt.

(Of course, first you need to install gettext and libintl from the
gnuwin32 project, or you can't even configure with --enable-nls)

cheers

andrew

OK, a few things. First, Tom has fixed snprintf.c so it should properly
process positional parameters now. Would you first test the libintl
version of *printf to see if it can process %$ parameters (probably by
hacking up any language file and testing the printing), and then try
your patch below to see if it is properly reorders the arguments. If
libintl does not reorder properly, but our snprintf.c does, would you
please generate an appliable patch we can put into 8.1.X? Thanks.

I know I am asking a lot, but you are "the man" on this one. :-)

---------------------------------------------------------------------------

Andrew Dunstan wrote:

Bruce Momjian wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that - windows
experts, please advise.

Plan A would be to make libpq export pg_snprintf and friends, Plan B
would be to give ecpg its own copy of snprintf.o. Plan A is probably
better since you're going to hit the same issue no doubt in all of the
src/bin programs.

I am confused why we would need either of these. All apps use
libpgport, and that pg_*printf should be in that library. The original
work Andrew did has problems particularly with ecpg, but why does ecpg
cause problems? Doesn't it link in pgport?

libpgtypes doesn't link with either libpgport or libpq.

What I have done to get a working build in addition to the previous
report is to undef snprintf and sprintf in
interfaces/pgtypeslib/extern.h (instead of creating an additional link
burden), and to add entries for pg_snprintf, pg_sprintf and pg_fprintf
to interfaces/libpq/exports.txt. That let me get a clean compile and
regression run. The diff against 8.1 is attached for comment.

I suspect we should probably add all the pg_*printf functions to
exports.txt.

(Of course, first you need to install gettext and libintl from the
gnuwin32 project, or you can't even configure with --enable-nls)

cheers

andrew

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

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

Bruce Momjian said:

OK, a few things. First, Tom has fixed snprintf.c so it should
properly process positional parameters now. Would you first test the
libintl version of *printf to see if it can process %$ parameters
(probably by hacking up any language file and testing the printing),
and then try your patch below to see if it is properly reorders the
arguments. If libintl does not reorder properly, but our snprintf.c
does, would you please generate an appliable patch we can put into
8.1.X? Thanks.

I know I am asking a lot, but you are "the man" on this one. :-)

Since the effect of the configure change I am proposing to reverse was to
force use of the *printf in libintl, don't we already know the answer to
your first question from Nicolai's report?

cheers

andrew

I wrote:

Bruce Momjian said:

OK, a few things. First, Tom has fixed snprintf.c so it should
properly process positional parameters now. Would you first test the
libintl version of *printf to see if it can process %$ parameters
(probably by hacking up any language file and testing the printing),
and then try your patch below to see if it is properly reorders the
arguments. If libintl does not reorder properly, but our snprintf.c
does, would you please generate an appliable patch we can put into
8.1.X? Thanks.

I know I am asking a lot, but you are "the man" on this one. :-)

Since the effect of the configure change I am proposing to reverse was to
force use of the *printf in libintl, don't we already know the answer to
your first question from Nicolai's report?

However, a very simple test shows that the libintl printf does indeed do
%m$ processing:

$ cat testpf.c
#include <libintl.h>
main()
{
printf("%2$s %1$s\n","arg1","arg2");
}
$ gcc -o testpf testpf.c -lintl
$ ./testpf.exe
arg2 arg1
$

So the next question is why isn't it working in the build.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

However, a very simple test shows that the libintl printf does indeed do
%m$ processing:
...
So the next question is why isn't it working in the build.

Is it possible that the build that was being complained of was using our
previous, very-broken snprintf.c?

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

However, a very simple test shows that the libintl printf does indeed do
%m$ processing:
...
So the next question is why isn't it working in the build.

Is it possible that the build that was being complained of was using our
previous, very-broken snprintf.c?

There's currently a config setting that is supposed to inhibit its use
on Windows. I am quite confused.

What is more, when I set the locale of my machine to Turkish and run the
installer project's 8.1_RC1 which I happen to have installed there, and
set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:

LOG: "$s" veritaban?n transaction ID warp limiti $u

I see this:

LOG: "2147484146" veritabanin transaction ID warp limiti postgres

So I'm inclined to think there might be something odd about his setup and maybe we aren't quite so broken after all.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

What is more, when I set the locale of my machine to Turkish and run the
installer project's 8.1_RC1 which I happen to have installed there, and
set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
LOG: "$s" veritaban?n transaction ID warp limiti $u
I see this:
LOG: "2147484146" veritabanin transaction ID warp limiti postgres

Well, that's pretty broken too :-(. The tr.po file entry is

msgid "transaction ID wrap limit is %u, limited by database \"%s\""
msgstr "\"%2$s\" veritabanın transaction ID warp limiti %1$u"

and if I'm not completely confused, correct translated output would be

"postgres" veritabanın transaction ID warp limiti 2147484146

Nicolai's report looks a bit like what you would expect from an sprintf
implementation that hadn't heard of %n$ specs at all. Your report looks
suspiciously like what our broken version of sprintf was producing last
week --- see
http://archives.postgresql.org/pgsql-hackers/2005-12/msg00194.php

How certain are you that that config setting is inhibiting use of
port/snprintf.c? It seems unlikely that any other implementation would
have duplicated our bug.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

What is more, when I set the locale of my machine to Turkish and run the
installer project's 8.1_RC1 which I happen to have installed there, and
set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
LOG: "$s" veritaban?n transaction ID warp limiti $u
I see this:
LOG: "2147484146" veritabanin transaction ID warp limiti postgres

Well, that's pretty broken too :-(. The tr.po file entry is

msgid "transaction ID wrap limit is %u, limited by database \"%s\""
msgstr "\"%2$s\" veritabanın transaction ID warp limiti %1$u"

and if I'm not completely confused, correct translated output would be

"postgres" veritabanın transaction ID warp limiti 2147484146

Nicolai's report looks a bit like what you would expect from an sprintf
implementation that hadn't heard of %n$ specs at all. Your report looks
suspiciously like what our broken version of sprintf was producing last
week --- see
http://archives.postgresql.org/pgsql-hackers/2005-12/msg00194.php

How certain are you that that config setting is inhibiting use of
port/snprintf.c? It seems unlikely that any other implementation would
have duplicated our bug.

Sorry ... I got into a muddle. I have rerun the tests.

With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
made yesterday, I see the result above, i.e. what we expect from our own
breakage of sprintf (i haven't yet updated the snapshot I took). I will
now try to verify that the changes you made in pg_sprintf do the right
thing.

We could ask why it appears that one version of libintl works (the one I
got the other day from gnuwin32) and one doesn't (the one that is in the
installer, apparently).

But the simple fix seems to be to use our version of printf and friends.
The changes requires are not too invasive.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
made yesterday, I see the result above, i.e. what we expect from our own
breakage of sprintf (i haven't yet updated the snapshot I took).

Ah. OK, that makes sense.

But the simple fix seems to be to use our version of printf and friends.
The changes requires are not too invasive.

I agree with doing this even if we weren't faced with (apparently)
multiple versions of libintl that don't all work alike. My thought is
that running our own version of snprintf on a heavily used port like
Windows is exactly what is needed to flush out any remaining bugs.
It's obviously not gotten enough field usage yet ...

Was the last patch you sent in ready for application, or are you still
fooling with it?

regards, tom lane