http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_mothdt=2010-05-13%2021:06:01
msgfmt -o po/ja.mo po/ja.po
WARNING: the string after closing is ignored at line number 11.
Error, No space after directive at line number 2008.
ERROR: Exiting...
gmake[2]: *** [po/ja.mo] Error 2
The problem
Takahiro Itagaki píše v pá 14. 05. 2010 v 19:38 +0900:
Zdenek Kotala zdenek.kot...@sun.com wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_mothdt=2010-05-13%2021:06:01
The problem is that it contains mix of DOS/Unix end of lines.
I removed two CRs in ja.po.
Thanks. Gothic
Hi Tom,
I'm sorry that I did not look on it early. I played with it and there
are some facts. gothic(sparc) and codlin(x86) uses Sun Studio 12 nad I
setup them to use very high optimization.
Gothic:
---
-xalias_level=basic -xarch=native -xdepend -xmemalign=8s -xO5
Dne 11.03.10 16:24, Greg Stark napsal(a):
On Wed, Mar 10, 2010 at 11:37 PM, Tom Lanet...@sss.pgh.pa.us wrote:
My conclusion is that this is probably a compiler bug. Both buildfarm
animals appear to be using Sun Studio, although on different
architectures which weakens the compiler-bug theory
Dne 11.03.10 17:37, Tom Lane napsal(a):
Zdenek Kotalazdenek.kot...@sun.com writes:
-xO4 -xalias_level=basic generates problem.
-xO3 -xalias_level=basic works fine
-xO5 works fine
As documentation say:
Cite from Sun studio compiler guide:
Tom Lane píše v čt 11. 03. 2010 v 11:37 -0500:
Zdenek Kotala zdenek.kot...@sun.com writes:
-xO4 -xalias_level=basic generates problem.
-xO3 -xalias_level=basic works fine
-xO5 works fine
As documentation say:
Cite from Sun studio compiler guide:
http://docs.sun.com/app/docs/doc
Magnus Hagander píše v po 01. 03. 2010 v 16:55 +0100:
2010/3/1 Zdenek Kotala zdenek.kot...@sun.com:
Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100:
On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala zdenek.kot...@sun.com wrote:
Hi all,
I got following stack:
fd7ffed14b70
Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100:
On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala zdenek.kot...@sun.com wrote:
Hi all,
I got following stack:
fd7ffed14b70 strlen () + 40
fd7ffed71665 snprintf () + e5
fd7fff36d088 pg_GSS_startup () + 88
Hi all,
I got following stack:
fd7ffed14b70 strlen () + 40
fd7ffed71665 snprintf () + e5
fd7fff36d088 pg_GSS_startup () + 88
fd7fff36d43a pg_fe_sendauth () + 15a
fd7fff36e557 PQconnectPoll () + 3b7
fd7fff36e152 connectDBComplete () + a2
fd7fff36dc32
Dne 17.02.10 18:39, Peter Eisentraut napsal(a):
On ons, 2010-02-17 at 11:26 -0500, Tom Lane wrote:
But the behavior gcc appears to exhibit is that it won't warn about
variables that are only assigned once before the PG_TRY is entered,
and that seems reasonable to me since such a variable ought
I revived codlin_month and it falls during PL/Python test:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=codlin_mothdt=2010-02-16%2015:09:05
TRAP: BadArgument(!(((context) != 0 (Node*)((context)))-type)
== T_AllocSetContext, File: mcxt.c, Line: 641)
feaf5005 _lwp_kill (1, 6,
Andrew Dunstan píše v po 08. 02. 2010 v 20:07 -0500:
Our Solaris *moth members seem to have stopped building. Have we lost them?
Hi Andrew,
The answer is not simple. Yes, we lost Solaris 8 and 9 machines which
was reinstalled and now they are used for different purpose. It was
planned before
I found following strange error on gothic moth:
== pgsql.22658/src/test/regress/regression.diffs
===
***
/zfs_data/home/postgres/buildfarm/gothic_moth/HEAD/pgsql.22658/src/test/regress/expected/vacuum.out
Tue Jan 12 22:06:13 2010
---
Dne 4.01.10 19:28, Alvaro Herrera napsal(a):
Bruce Momjian escribió:
I considered that but realize that pg_migrator has to read
pg_controldata in both the old and new servers, meaning it would need
access to both C structures, and considering they both have the same
structure names, that
Greg Smith píše v út 15. 12. 2009 v 12:10 -0500:
Please send that updated version, and let's keep working on this into
the next CommitFest, where it will be in the front of the queue rather
than how it ended up at the tail of this one just based on its
submission date. You're not really
Bernd Helmle píše v po 14. 12. 2009 v 20:42 +0100:
--On 14. Dezember 2009 20:33:12 +0100 Bernd Helmle maili...@oopsware.de
wrote:
Since the author has pretty much admitted he didn't fix any of the
issues that were raised by the last committer review, I'm a little
confused about why
Bernd Helmle píše v pá 11. 12. 2009 v 17:13 +0100:
--On 11. Dezember 2009 11:28:54 -0300 Alvaro Herrera
alvhe...@commandprompt.com wrote:
without compiled probes: AVG(2531.68)
with compiled probes: AVG(2511.97)
Were the probes enabled?
Hmm, they were just compiled in, i didn't
Robert Haas píše v čt 10. 12. 2009 v 23:55 -0500:
On Wed, Dec 9, 2009 at 9:04 AM, Zdenek Kotala zdenek.kot...@sun.com wrote:
But in normal situation database does also other thing and palloc is
only one part of code path. It is why I run second test and use sun
studio profiling tools
Robert Haas píše v pá 11. 12. 2009 v 12:55 -0500:
On Fri, Dec 11, 2009 at 12:55 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Bernd Helmle píše v pá 11. 12. 2009 v 17:13 +0100:
--On 11. Dezember 2009 11:28:54 -0300 Alvaro Herrera
alvhe...@commandprompt.com wrote:
without compiled
Tom Lane píše v pá 11. 12. 2009 v 13:56 -0500:
Robert Haas robertmh...@gmail.com writes:
As far as I am concerned that is way too much, particularly
considering that your test case isn't designed to be particularly
memory-allocation intensive, and if it is up to me I will reject this.
Tom Lane píše v pá 11. 12. 2009 v 14:38 -0500:
Robert Haas robertmh...@gmail.com writes:
I thought we had an idea of using the AllocSet dispatch mechanism to
make this zero-overhead in the case where the probes are not enabled.
What happened to that notion?
I must have missed that
Tom Lane píše v pá 11. 12. 2009 v 15:11 -0500:
Zdenek Kotala zdenek.kot...@sun.com writes:
I thought about it. I think we can use GUC variable (e.g. dtraced_alloc)
and hook switch pointers to dtraced AsetFunctions. The problem is how to
distribute to all backend.
You set the GUC
Dne 10.12.09 15:51, Bernd Helmle napsal(a):
--On 8. Dezember 2009 11:10:44 +0100 Zdenek Kotala
zdenek.kot...@sun.com wrote:
If you think that it is better I could split patch into two separate
patches and both can be reviewed separately.
I split up this patch into two separate patches
Frank Ch. Eigler píše v čt 10. 12. 2009 v 14:11 -0500:
Zdenek Kotala zdenek.kot...@sun.com writes:
[...]
+ header = (StandardChunkHeader *)
+ ((char *) ret - STANDARDCHUNKHEADERSIZE);
+
+// TRACE_POSTGRESQL_MCXT_ALLOC(context-name, context, size, header-size,
true
Greg Smith píše v út 08. 12. 2009 v 22:44 -0500:
Zdenek Kotala wrote:
thanks for your useful comments. I attached new doc patch version. I
removed example changes and add link to create database cluster (I hope)
everywhere. Please, look on it and let me know if there is still
something
Bernd Helmle píše v út 08. 12. 2009 v 22:06 +0100:
--On 8. Dezember 2009 15:51:52 -0500 Greg Smith g...@2ndquadrant.com
wrote:
Try this instead, which will give you a test where checkpoints have a
minimal impact, but lots of memory will be thrown around:
pgbench -i -s 10 db
Robert Haas píše v st 09. 12. 2009 v 08:56 -0500:
On Dec 9, 2009, at 8:32 AM, Zdenek Kotala zdenek.kot...@sun.com wrote:
snip
Ahh, It is somethink what I want to do, but it is not ready yet in
this
patch, but I already documented it. Idea is to install initdb and
postgres
Dne 8.12.09 00:27, Bernd Helmle napsal(a):
--On 13. November 2009 23:29:41 +0100 Zdenek Kotala
zdenek.kot...@sun.com wrote:
t contains two DTrace probe groups. One is related to monitoring SLRU
and second is about executor nodes.
I merged it with the head.
Original end of mail thread
Greg,
thanks for your useful comments. I attached new doc patch version. I
removed example changes and add link to create database cluster (I hope)
everywhere. Please, look on it and let me know if there is still
something what should be changed.
Thanks Zdenek
Greg Smith píše v ne 06.
I attached updated patch and doc patch.
Zdenek
Peter Eisentraut píše v so 21. 11. 2009 v 13:19 +0200:
On lör, 2009-11-14 at 14:50 +0100, Zdenek Kotala wrote:
Peter Eisentraut píše v so 14. 11. 2009 v 10:41 +0200:
On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote
Bruce Momjian píše v po 30. 11. 2009 v 12:32 -0500:
Zdenek Kotala wrote:
collateindex.pl is stored in /usr/share/sgml/docbook/. Attached fix
modify docbook.m4 to find correct path.
It would be nice also backported the fix back at least to 8.2.
I am not happy looking in a directory
Peter Eisentraut píše v po 30. 11. 2009 v 21:27 +0200:
On mån, 2009-11-30 at 19:53 +0100, Zdenek Kotala wrote:
Bruce Momjian píše v po 30. 11. 2009 v 12:32 -0500:
I am not happy looking in a directory _above_ a specified directory by
default:
[$DOCBOOKSTYLE/bin
collateindex.pl is stored in /usr/share/sgml/docbook/. Attached fix
modify docbook.m4 to find correct path.
It would be nice also backported the fix back at least to 8.2.
Thanks Zdenek
diff -r 2d87758e836b config/docbook.m4
--- a/config/docbook.m4 Sun Nov 22 22:06:30 2009 +
+++
Peter Eisentraut píše v so 14. 11. 2009 v 10:41 +0200:
On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote:
Attached patch extends pg_ctl command with init option.
pg_ctl -D /var/lib/postgres [-s] init
This should replace usage of initdb command which has problematic name
as we
Hmm, const is also problem on solaris. dtrace generates probe.h file and
eats const. It generates following noise on solaris build:
postgres.c, line 554: warning: argument #1 is incompatible with
prototype:
prototype: pointer to char : ../../../src/include/utils/probes.h,
line 582
Attached patch fixed following warning:
../../../src/include/nodes/parsenodes.h, line 487: warning: enumerator
value overflows INT_MAX (2147483647)
The reason is clear, enum is int not unsigned.
It is short fix, but I'm thinking about enum conversion to #define. We
use e.g. in the same file.
Attached patch contains new dtrace probes for memory management. Main
purpose is to analyze memory footprint - for example how many memory
needs transaction, peak memory per context, when memory block is reused
or when it is allocate by malloc and so on.
There are three groups of probes:
1)
Tom Lane píše v pá 13. 11. 2009 v 16:06 -0500:
Zdenek Kotala zdenek.kot...@sun.com writes:
Attached patch contains new dtrace probes for memory management.
This is a bad idea and I want to reject it outright. No ordinary user
is really going to care about those details, and palloc
Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300:
Zdenek Kotala wrote:
Attached patch contains new dtrace probes for memory management. Main
purpose is to analyze memory footprint - for example how many memory
needs transaction, peak memory per context, when memory block is reused
Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300:
Zdenek Kotala wrote:
Attached patch contains new dtrace probes for memory management. Main
purpose is to analyze memory footprint - for example how many memory
needs transaction, peak memory per context, when memory block is reused
I attached patch which was already sent on february/april, but it was
lost in time. It is originally from Robert Lor and Theo Schlossnagle.
It contains two DTrace probe groups. One is related to monitoring SLRU
and second is about executor nodes.
I merged it with the head.
Original end of mail
u235sentinel píše v út 20. 10. 2009 v 12:22 -0600:
Now I'm running and will add a few more things in like readline. The
goal is to build plr and plperl and load them into postgres.
Hmm, I'm afraid that 64bit plperl is a problem. Solaris 10 is not
shipped with 64bit perl :(.
Zdenek
is recommending we flatten
the Sun box and install redhat linux (which I'm fine with). I'd rather
not as threading in Solaris is better.
Thoughts?
thanks
Zdenek Kotala wrote:
You can look on
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ghost_mothdt=2009-10-07%2021:06:00
Andrew Chernow píše v ne 18. 10. 2009 v 21:09 -0400:
I'm curious if this is a lost hope. My boss is recommending we flatten
the Sun box and install redhat linux (which I'm fine with). I'd rather
not as threading in Solaris is better.
Maybe solaris threads were better 10-15 years ago,
Andrew Chernow píše v po 19. 10. 2009 v 14:14 -0400:
# ./pg_ctl
ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
/usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
0xfd7fff1cf210 does not fit
Killed
symbol (unknown). Can you turn on debugging symbols?
You can look on
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ghost_mothdt=2009-10-07%2021:06:00
How it is built. You also does not needed own version of Openssl. All
security fixes are backported. It is located in /usr/sfw/lib or
/usr/sfw/lib/64
Sometimes are problem with gcc and
Tom Lane píše v čt 01. 10. 2009 v 12:28 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
I'm looking why cometh_month fails and it is problem with last hstore
putback:
I think this is the same 64-bit problem we fixed last night --- wait for
the next rebuild before worrying.
Correct
I'm looking why cometh_month fails and it is problem with last hstore
putback:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_mothdt=2009-09-30%2021:06:00
Stack trace is following:
6f013828 hstore_hash (7fffa050, 1395298, 1, 41,
7370616365414143, 0) + c0
Peter Eisentraut píše v čt 17. 09. 2009 v 23:00 +0300:
On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote:
Attached patch extends pg_ctl command with init option.
pg_ctl -D /var/lib/postgres [-s] init
This should replace usage of initdb command which has problematic name
as we
Attached patch extends pg_ctl command with init option.
pg_ctl -D /var/lib/postgres [-s] init
This should replace usage of initdb command which has problematic name
as we already discussed several times. Initdb binary will be still
there, but it can be renamed and move into execlib dir in the
You can see strange error on gothic moth (Solaris Nevada, SunStudio 12,
Sparc):
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2009-09-08%2019:06:01
= pgsql.19404/contrib/tsearch2/regression.diffs
===
*** ./expected/tsearch2.out Tue Sep 8
Dne 5.09.09 00:09, Josh Berkus napsal(a):
On 9/4/09 2:49 PM, Tom Lane wrote:
Wasn't anybody paying attention?
Apparently nobody is using it on other platforms. I know I'm not.
I think that buildfarm members can enable it for supported platform. I
already did it for my machine.
If you look on gothic_moth and comet_moth
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2009-08-30%2020:06:00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_mothdt=2009-08-29%2021:06:00
you can see following error:
../../src/test/regress/pg_regress --inputdir=.
Tom Lane píše v po 31. 08. 2009 v 11:00 -0400:
3. Push the startup-packet GUC processing (approx. lines 3340..3395 of
postgres.c, as of CVS HEAD) into InitPostgres, so it can be run during
the startup transaction. This is not too unclean, though it would
mean exporting
Tom Lane píše v so 22. 08. 2009 v 09:56 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
There are most important records from yesterdays issues.
Messages:
-
Aug 20 11:14:54 genunix: [ID 470503 kern.warning] WARNING: Sorry, no swap
space to grow stack for pid 507 (postgres
Zdenek Kotala píše v po 24. 08. 2009 v 13:47 +0200:
I tested Alvaro's patch and it works, because it does not lead to stack
consumption, but it shows another bug in StartAutovacuumWorker() code.
When fork fails bn structure is freed but
ReleasePostmasterChildSlot() should be called as well
Alvaro Herrera píše v pá 21. 08. 2009 v 17:48 -0400:
Tom Lane wrote:
I'd still like to have some fork-rate-limiting behavior in there
somewhere. However, it might make sense for the avlauncher to do that
rather than the postmaster. Does that idea seem more implementable?
snip
Does
Tom Lane píše v pá 21. 08. 2009 v 18:06 -0400:
Maybe, but I think we need to understand exactly what happened first.
I try to mine more data from the system to reconstruct what happen.
Unfortunately, default postgresql log configuration does not have
timestamp. The postgresql had no load,
I found following core file of PG 8.4.0 on my system (Solaris Nevada
b119):
fe8ae42d _dowrite (85bf6e8, 3a, 8035e3c, 80350e8) + 8d
fe8ae743 _ndoprnt (85bf6e8, 8035ec8, 8035e3c, 0) + 2ba
fe8b322d vsnprintf (85bfaf0, 3ff, 85bf6e8, 8035ec8, 0, 0) + 65
082194ea appendStringInfoVA (8035e9c,
Alvaro Herrera píše v pá 21. 08. 2009 v 15:40 -0400:
Zdenek Kotala wrote:
The problem what I see here is that StartAutovacuumWorker() fails and
send SIGUSR1 to the postmaster, but it send it too quickly and signal
handler is still active. When signal mask is unblocked
Dne 24.07.09 19:23, Emanuel Calvo Franco napsal(a):
Hi all,
I have some issues to compile uuid contrib of 8.4 version.
Touching something i see that the gmake don't find uuid.h.
(pfexec gmake -d)
Touching more, i add uuid.h into the uuid directory and i had a
error message: missing separator.
I attached conservative version of patch which only reorder #define to
avoid cross including half from readline and half from editline.
Zdenek
Tom Lane píše v čt 06. 08. 2009 v 18:13 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
It seems to me that editline never distributed
Dne 7.08.09 00:13, Tom Lane napsal(a):
Zdenek Kotala zdenek.kot...@sun.com writes:
It seems to me that editline never distributed history.h file and
HAVE_EDITLINE_HISTORY_H is nonsense. But I'm not sure.
I wouldn't count on that, in part because there are so many versions of
editline
Dne 6.08.09 04:29, Tom Lane napsal(a):
Andrew Dunstan and...@dunslane.net writes:
preventing a clash might be fairly difficult.
Yeah, I was just thinking about that. The easiest way to avoid
collisions would be to make pg_dump (in --binary-upgrade mode)
responsible for being sure that
When I try compile postgresql with --libeditpreferred option,
compilation fails when readline is also installed on the system. You can
see error report on:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dot_mothdt=2009-08-06%2012:46:04
The main problem is in src/bin/psql/input.h where is
It seems that last contrib crypto changes broke buildfarm. You can see
problem e.g. here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emperor_mothdt=2009-08-04%2020:06:01
I don't have time to look on it now. But it should be reproducible
everywhere.
Zdenek
--
Sent via
Grzegorz Jaskiewicz píše v čt 16. 07. 2009 v 14:59 +0100:
Why C89, and not C99 ? Virtually all compilers for last 4 years have/
had C99 support.
Well, I think we want to run on systems that are older than 4 years,
too.
Sure, but that's probably less than 1% of all systems.
Dne 14.07.09 04:37, Bruce Momjian napsal(a):
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tilmann Singer wrote:
However, all of the sequences were at the initial values and not
bumped up to the last used value as I would have expected. The first
nextval call on any
Tom Lane píše v čt 02. 07. 2009 v 13:13 -0400:
Actually, most of the buildfarm members show which flex version they are
running in the configure output. A quick look shows that of the 45
members that have reported on HEAD in the past 2 days, 22 are running
2.5.4, which is a lot higher
Peter Eisentraut píše v pá 03. 07. 2009 v 09:19 +0300:
On Friday 03 July 2009 05:16:41 Robert Haas wrote:
On Thu, Jul 2, 2009 at 3:42 PM, Zdenek Kotalazdenek.kot...@sun.com wrote:
Josh Berkus píše v st 01. 07. 2009 v 17:21 -0700:
Folks,
There's been a lot of discussion/argument
Robert Haas píše v čt 02. 07. 2009 v 22:16 -0400:
On Thu, Jul 2, 2009 at 3:42 PM, Zdenek Kotalazdenek.kot...@sun.com wrote:
Also, how would we handle changes by committers, who
don't always go through the CommitFest process?
I think that all head patches should go to through a new tool for
Tom Lane píše v čt 02. 07. 2009 v 11:32 -0400:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Right, this will only affect people doing development or otherwise
building from a CVS pull.
Of course, that includes the whole buildfarm. We might need to ask some
people to
Tom Lane píše v čt 02. 07. 2009 v 13:13 -0400:
I wrote:
Yes. What I was thinking of doing was committing a configure change to
reject flex 2.5.31, and waiting to see how much of the buildfarm goes
red.
Actually, most of the buildfarm members show which flex version they are
running
Josh Berkus píše v st 01. 07. 2009 v 17:21 -0700:
Folks,
There's been a lot of discussion/argument around how to handle the last
commitfest, but there seems to be a total consensus that we want to have
the first CF on July 15th.
Can we add flags like bump catalog version, bump page
Zdenek Kotala píše v po 01. 06. 2009 v 22:45 +0200:
Tom Lane píše v po 01. 06. 2009 v 16:09 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
What is sys/list.h, and why is it being imported by the Perl headers?
It seems that problem is with Perl. It includes sys/mode.h. The new
During integration gcc4.2 into Solaris. My colleague hit a following
problem with PostgreSQL compilation:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6845982
cd
/builds/sfw-fixes/usr/src/cmd/postgres/postgresql-8.2/postgresql-8.2.13/src/pl/plperl
+
Robert Haas píše v po 01. 06. 2009 v 16:03 -0400:
On Mon, Jun 1, 2009 at 3:57 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
During integration gcc4.2 into Solaris. My colleague hit a following
problem with PostgreSQL compilation:
http://bugs.opensolaris.org/bugdatabase/view_bug.do
Tom Lane píše v po 01. 06. 2009 v 16:09 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
What is sys/list.h, and why is it being imported by the Perl headers?
It seems that problem is with Perl. It includes sys/mode.h. The new
change for gcc 4.2 is that mode.h includes vnode.h
Bruce Momjian píše v čt 28. 05. 2009 v 17:20 -0400:
Done, patch attached and applied.
I went with a warning because it seemed most appropriate, but it looks
very large:
http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html
Should it be a notice?
I prefer
Tom Lane píše v čt 28. 05. 2009 v 11:42 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
I attached another cleanup patch which fixes following warnings reported
by Sun Studio:
I'm not too impressed with any of these. The proposed added
initializers just increase future maintenance
Tom Lane píše v čt 28. 05. 2009 v 11:57 -0400:
).
AFAICS, Sun's compiler is just too stupid and shouldn't be emitting
this warning. Perhaps the right response is to file a bug report
against the compiler.
I checked it and it is already know bug. It is new lint style check in
Sun Studio
Bruce Momjian píše v čt 28. 05. 2009 v 17:42 -0400:
Josh Berkus wrote:
On 5/28/09 2:30 PM, Bruce Momjian wrote:
Because no one has responded, I am going to prevent pg_migrator from
working with a cluster that uses tsvector. I realize this limits
pg_migrator's usefulness, but I have
Tom Lane píše v pá 29. 05. 2009 v 11:28 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
The biggest problem is dictionary change. I'm not sure if it happened
but IIRC Teodor mentioned it in Ottawa. If it happened It hits down
tsvector compatibility at all.
No more than changing
I attached another cleanup patch which fixes following warnings reported
by Sun Studio:
zic.c, line 1534: warning: const object should have initializer: tzh0
dynloader.c, line 7: warning: empty translation unit
pgstat.c, line 666: warning: const object should have initializer: all_zeroes
Michael Meskes píše v čt 28. 05. 2009 v 13:33 +0200:
On Thu, May 28, 2009 at 11:11:20AM +0200, Zdenek Kotala wrote:
I attached another cleanup patch which fixes following warnings reported
by Sun Studio:
...
preproc.c, line 39569: warning: pointer expression or its operand do
Michael Meskes píše v čt 28. 05. 2009 v 14:47 +0200:
On Thu, May 28, 2009 at 01:51:07PM +0200, Zdenek Kotala wrote:
Problem is with YYLLOC_DEFAULT. When I look on macro definition
#define YYLLOC_DEFAULT(Current, Rhs, N) \
Current.first_line = Rhs[1].first_line
Peter Eisentraut píše v út 26. 05. 2009 v 13:39 +0300:
Of course the concrete example that you show doesn't actually take advantage
of this, so if it is important to you, please send a patch to fix it.
Fix attached. I found only two problems, both in psql. I did not fix .po
files. Is
Here is output of:
for FILE in `find . -name *.po`;do LC_ALL=C msgfmt -v -o /dev/null $FILE
2 msgfmt.txt; done
Zdenek
Peter Eisentraut píše v st 27. 05. 2009 v 23:08 +0300:
On Monday 25 May 2009 19:11:24 Zdenek Kotala wrote:
The problem here is (1 row) instead of (%lu row). When I
Peter Eisentraut píše v út 26. 05. 2009 v 13:39 +0300:
On Monday 25 May 2009 19:11:24 Zdenek Kotala wrote:
snip
The problem here is (1 row) instead of (%lu row). When I run msgfmt
without -v everything works fine but I think we should fixed it (there
are more occurrences of this issue
Tom Lane píše v po 25. 05. 2009 v 13:07 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
Tom Lane píše v ne 24. 05. 2009 v 18:46 -0400:
In any case, the barriers to implementing 8.3-style hash indexes in 8.4
are pretty huge: you'd need to duplicate not only the hash AM code, but
also
Peter Eisentraut píše v ne 24. 05. 2009 v 00:40 +0300:
I think this is not the best way to do it, because it will confuse pgindent
and editors and such. The DATA() macros in include/catalog have this solved;
see include/catalog/genbki.sh.
Attached variant with faked extern without ; which
Tom Lane píše v ne 24. 05. 2009 v 18:46 -0400:
Kenneth Marshall k...@rice.edu writes:
On Sat, May 23, 2009 at 02:52:49PM -0400, Zdenek Kotala wrote:
Attached patch cleanups hash index headers to allow compile hasham for
8.3 version. It helps to improve pg_migrator with capability
I tried to run msgfmt -v ... on solaris and I got following error:
Processing file psql-cs.po...
GNU PO file found.
Generating the MO file in the GNU MO format.
Processing file psql-cs.po...
Lines 1311, 1312 (psql-cs.po): incompatible printf-format.
0 format specifier(s) in msgid, but 1
I forgot to fix contrib. Updated patch attached.
Zdenek
Zdenek Kotala píše v pá 22. 05. 2009 v 16:23 -0400:
Attached patch cleanups hash index headers to allow compile hasham for
8.3 version. It helps to improve pg_migrator with capability to migrate
database with hash index
Heikki Linnakangas píše v čt 21. 05. 2009 v 16:53 +0300:
Zdenek Kotala wrote:
Another problem is with resultset. When I run for example following
command I got this output:
postgres=# select oid from pg_am;
oid
--
403
405
783
2742
That's odd. Work
When I compile postgresql now I get following message:
../../../src/include/access/reloptions.h, line 45: warning: integer
overflow detected: op
The problem is on the following lines
typedef enum relopt_kind
{
...
RELOPT_KIND_MAX = (1 31)
}
enum is int datatype and 1 31 ==
Attached patch cleanups hash index headers to allow compile hasham for
8.3 version. It helps to improve pg_migrator with capability to migrate
database with hash index without reindexing.
I discussed this patch year ago with Alvaro when we tried to cleanup
include bloating problem. It should
Attached patch fixes following sun studio compiler warning:
tsquery_op.c, line 193: warning: syntax error: empty declaration
tsquery_op.c, line 194: warning: syntax error: empty declaration
tsquery_op.c, line 195: warning: syntax error: empty declaration
tsquery_op.c, line 196: warning: syntax
Hi all,
last version of psql is broken:
psql (8.4beta1, server 8.3.7)
WARNING: psql version 8.4, server version 8.3.
Some psql features might not work.
Type help for help.
postgres=# \d test
ERROR: syntax error at or near ,
LINE 1: ...index, relhasrules, reltriggers 0, relhasoids,
Heikki Linnakangas píše v čt 21. 05. 2009 v 16:53 +0300:
Zdenek Kotala wrote:
last version of psql is broken:
psql (8.4beta1, server 8.3.7)
WARNING: psql version 8.4, server version 8.3.
Some psql features might not work.
Type help for help.
postgres=# \d test
ERROR
1 - 100 of 699 matches
Mail list logo
