Takahiro Itagaki píše v pá 14. 05. 2010 v 19:38 +0900:
> Zdenek Kotala wrote:
>
> > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_moth&dt=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
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_moth&dt=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
Tom Lane píše v čt 11. 03. 2010 v 11:37 -0500:
> Zdenek Kotala writes:
> > "-xO4 -xalias_level=basic" generates problem.
> > "-xO3 -xalias_level=basic" works fine
> > "-xO5" works fine
>
> > As documentation say:
>
> > Cite
Dne 11.03.10 17:37, Tom Lane napsal(a):
Zdenek Kotala 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/
Dne 11.03.10 16:24, Greg Stark napsal(a):
On Wed, Mar 10, 2010 at 11:37 PM, Tom Lane 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 a bit. Even though
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
-xprefetch=auto,explici
Magnus Hagander píše v po 01. 03. 2010 v 16:55 +0100:
> 2010/3/1 Zdenek Kotala :
> > Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100:
> >> On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala wrote:
> >> > Hi all,
> >> >
> >> > I got following
Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100:
> On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala wrote:
> > Hi all,
> >
> > I got following stack:
> >
> > fd7ffed14b70 strlen () + 40
> > fd7ffed71665 snprintf () + e5
> > fd7fff36d088
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 PQsetdbLogi
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 t
I revived codlin_month and it falls during PL/Python test:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=codlin_moth&dt=2010-02-16%2015:09:05
TRAP: BadArgument("!(((context) != 0 && (Node*)((context)))->type)
== T_AllocSetContext", File: "mcxt.c", Line: 641)
feaf5005 _lwp_kill
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 befor
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
---
/zfs_data/home/postgres/bu
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 would
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
> 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 you're ask
Tom Lane píše v pá 11. 12. 2009 v 15:11 -0500:
> Zdenek Kotala 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
Tom Lane píše v pá 11. 12. 2009 v 14:38 -0500:
> Robert Haas 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 discussion, but +1
Tom Lane píše v pá 11. 12. 2009 v 13:56 -0500:
> Robert Haas 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.
> > Even a quarter-
Robert Haas píše v pá 11. 12. 2009 v 12:55 -0500:
> On Fri, Dec 11, 2009 at 12:55 PM, Zdenek Kotala wrote:
> > Bernd Helmle píše v pá 11. 12. 2009 v 17:13 +0100:
> >>
> >> --On 11. Dezember 2009 11:28:54 -0300 Alvaro Herrera
> >> wrote:
> >>
> &g
Robert Haas píše v čt 10. 12. 2009 v 23:55 -0500:
> On Wed, Dec 9, 2009 at 9:04 AM, Zdenek Kotala 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
> > stud
Bernd Helmle píše v pá 11. 12. 2009 v 17:13 +0100:
>
> --On 11. Dezember 2009 11:28:54 -0300 Alvaro Herrera
> 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 anything
Frank Ch. Eigler píše v čt 10. 12. 2009 v 14:11 -0500:
> Zdenek Kotala writes:
>
> > [...]
> > + header = (StandardChunkHeader *)
> > + ((char *) ret - STANDARDCHUNKHEADERSIZE);
> > +
> > +// TRACE_POSTGRESQL_MCXT_ALLOC(context->name,
Dne 10.12.09 15:51, Bernd Helmle napsal(a):
--On 8. Dezember 2009 11:10:44 +0100 Zdenek Kotala
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: one for SLRU and one
Robert Haas píše v st 09. 12. 2009 v 08:56 -0500:
> On Dec 9, 2009, at 8:32 AM, Zdenek Kotala wrote:
> >
> > 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
>
Bernd Helmle píše v út 08. 12. 2009 v 22:06 +0100:
>
> --On 8. Dezember 2009 15:51:52 -0500 Greg Smith
> 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
> > pgbench -S -c 1
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 k
Dne 8.12.09 00:27, Bernd Helmle napsal(a):
--On 13. November 2009 23:29:41 +0100 Zdenek Kotala
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 is here:
http
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 +0
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 director
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.
>
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 +
+++ b/conf
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
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 ini
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 t
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 m
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 m
Tom Lane píše v pá 13. 11. 2009 v 16:06 -0500:
> Zdenek Kotala 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 is a
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) gener
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.
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
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 debugg
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 year
> 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.
>
> Thoughts?
>
> thanks
>
>
> Zdenek Kotala wrote:
> >
You can look on
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ghost_moth&dt=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 sola
Tom Lane píše v čt 01. 10. 2009 v 12:28 -0400:
> Zdenek Kotala 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 w
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_moth&dt=2009-09-30%2021:06:00
Stack trace is following:
6f013828 hstore_hash (7fffa050, 1395298, 1, 41,
7370616365414143, 0) + c0
00
Bernd Helmle píše v čt 17. 09. 2009 v 23:26 +0200:
>
> --On 17. September 2009 23:00:12 +0300 Peter Eisentraut
> wrote:
>
> > f the name is a problem, why not change the name? What you are
> > proposing above is effectively a very elaborate name change, so why not
> > go for a simpler one?
>
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 ini
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 fu
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.
You can see strange error on gothic moth (Solaris Nevada, SunStudio 12,
Sparc):
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-09-08%2019:06:01
= pgsql.19404/contrib/tsearch2/regression.diffs
===
*** ./expected/tsearch2.out Tue Sep 8
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 process_postgres_sw
If you look on gothic_moth and comet_moth
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-08-30%2020:06:00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_moth&dt=2009-08-29%2021:06:00
you can see following error:
../../src/test/regress/pg_regress --inputdir=.
--psq
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() sh
Tom Lane píše v so 22. 08. 2009 v 09:56 -0400:
> Zdenek Kotala 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 stac
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, syst
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?
>
>
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 sig
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, 85bf6e8
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 writes:
> > It seems to me that editline never distributed history.h
Dne 6.08.09 04:29, Tom Lane napsal(a):
Andrew Dunstan 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 *every* new pg_type and p
Dne 7.08.09 00:13, Tom Lane napsal(a):
Zdenek Kotala 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. On an OS X mac
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_moth&dt=2009-08-06%2012:46:04
The main problem is in src/bin/psql/input.h where is foll
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_moth&dt=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 pgsql-ha
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
Dne 14.07.09 04:37, Bruce Momjian napsal(a):
Tom Lane wrote:
Bruce Momjian 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 sequence in the mig
Robert Haas píše v čt 02. 07. 2009 v 22:16 -0400:
> On Thu, Jul 2, 2009 at 3:42 PM, Zdenek Kotala 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
rec
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 Kotala wrote:
> > > Josh Berkus píše v st 01. 07. 2009 v 17:21 -0700:
> > >> Folks,
> > >>
> > >
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
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 l
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
>
Tom Lane píše v čt 02. 07. 2009 v 11:32 -0400:
> Andrew Dunstan 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 upgrade
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 writes:
>
>
> > What is , and why is it being imported by the Perl headers?
>
> It seems that problem is with Perl. It includes sys/mode.h. The
Tom Lane píše v po 01. 06. 2009 v 16:09 -0400:
> Zdenek Kotala writes:
> What is , 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 and it finally
sys/list.h wh
Robert Haas píše v po 01. 06. 2009 v 16:03 -0400:
> On Mon, Jun 1, 2009 at 3:57 PM, Zdenek Kotala wrote:
> > During integration gcc4.2 into Solaris. My colleague hit a following
> > problem with PostgreSQL compilation:
> >
> > http://bugs.opensolaris.org/bugdatabase
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
+ /ws/onnv-tools/SUNWspro/SS12/bin
Tom Lane píše v pá 29. 05. 2009 v 11:28 -0400:
> Zdenek Kotala 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.
>
>
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, b
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 Studi
Tom Lane píše v čt 28. 05. 2009 v 11:42 -0400:
> Zdenek Kotala 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 futu
Bruce Momjian píše v čt 28. 05. 2009 v 17:20 -0400:
> >
> > Done, patch attached and applied.
>
> I went with a 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 war
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
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:
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
"pg
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
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 necess
Tom Lane píše v po 25. 05. 2009 v 13:07 -0400:
> Zdenek Kotala 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 has
Peter Eisentraut píše v út 26. 05. 2009 v 13:39 +0300:
> On Monday 25 May 2009 19:11:24 Zdenek Kotala wrote:
> >
> > 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
> > a
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
Tom Lane píše v ne 24. 05. 2009 v 18:46 -0400:
> Kenneth Marshall 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_mi
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 ; whi
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
> >
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
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:
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 reduc
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 ==
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.
> >
1 - 100 of 703 matches
Mail list logo
