Re: [BUGS] Failure in "make check" with 7.4RC2
Wolfgang Drotschmann <[EMAIL PROTECTED]> writes: > In an effort to answer your question above, I started again from scratch on > the same machine... And you guess it - the checks went through. > I don't know what happend that day. > I'm sorry if I raised some dust! Well, there's something odd going on, because you're not the first to report build failures centering on "get_progname". It'd be nice if we could isolate the difference between the cases that work and the cases that don't ... regards, tom lane ---(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: [BUGS] Failure in "make check" with 7.4RC2
Hallo Tom! Sorry for being late on this... Short version: Problem solved, reason remains a mystery. Hmm. get_progname() should be getting linked into the createdb executable by way of libpgport.a from the src/port/ directory. Can you look at the build process in src/port/ and src/bin/scripts/ and try to see what went wrong? The only idea that comes to mind is that a wrong (old) copy of libpgport got picked up somehow, but seeing that we don't install it, it's not clear how there could be an old copy anywhere. Long version: Before I wrote the first mail, I checked two times whether I could reproduce this behaviour. First, I made a "make distclean" before compiling and checking again. Then, I even removed the whole thing and started from zero. Both times I got this error message. In an effort to answer your question above, I started again from scratch on the same machine... And you guess it - the checks went through. I don't know what happend that day. I'm sorry if I raised some dust! Best regards, Wolfgang ---(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
[BUGS] lower('Å') or upper('å') gives improper results.
Hi,
Please find the output of the simple query :
sfa_db=> select upper('å');
upper
---
å
(1 row)
PostGRESql doesn't convert the special characters like Å, Ò, etc into their lower case
when using function lower and vice-versa when using upper.
Neha
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] lower('Å') or upper('å') gives imp
Neha Kasat writes: > PostGRESql doesn't convert the special characters like Å, Ò, etc into > their lower case when using function lower and vice-versa when using > upper. It does if you select the right locale. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] lower('Å') or upper('å') gives imp
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Neha Kasat writes: >> PostGRESql doesn't convert the special characters like Å, Ò, etc into >> their lower case when using function lower and vice-versa when using >> upper. > It does if you select the right locale. ... and character set. We don't have support for this yet in multibyte character sets (like Unicode). You need to pick an appropriate ISO encoding and a suitable locale setting. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] RC2 will not make check on OSX 10.3
After about two hours of hunting pecking and anything else I found where you control this in OSX 10.3 you must edit the /etc/rc file. /System/Library/StartupItems/SystemTuning/SystemTuning does nothing now.. 7.4 RC2 make check only fails on the geometry test type_sanity ... ok opr_sanity ... ok test geometry ... FAILED test horology ... ok test insert ... ok test create_function_1... ok test create_type ... ok I hope if someone searches on OSX (OS X) SystemTuning they find this edit rc... on about the second page you will find the settings. This is what I have and it is working... I don't know if it is optimal.. Ted # System tuning sysctl -w kern.maxvnodes=$(echo $(sysctl -n hw.physmem) '33554432 / 512 * 1024 +p'|dc) sysctl -w kern.sysv.shmmax=167772160 sysctl -w kern.sysv.shmmin=1 sysctl -w kern.sysv.shmmni=32 sysctl -w kern.sysv.shmseg=8 sysctl -w kern.sysv.shmall=65536 --- Tom Lane <[EMAIL PROTECTED]> wrote: > Theodore Petrosky <[EMAIL PROTECTED]> writes: > > FATAL: could not create shared memory segment: > Cannot > > allocate memory > > DETAIL: Failed system call was shmget(key=1, > > size=1081344, 03600). > > You need to increase SHMMAX. > > regards, tom lane > > ---(end of > broadcast)--- > TIP 3: if posting/reading through Usenet, please > send an appropriate > subscribe-nomail command to > [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] RC2 will not make check on OSX 10.3
Theodore Petrosky <[EMAIL PROTECTED]> writes: > After about two hours of hunting pecking and anything > else I found where you control this in OSX 10.3 > > you must edit the /etc/rc file. > > /System/Library/StartupItems/SystemTuning/SystemTuning > does nothing Should we update the documentation's advice? At present, it suggests: MacOS X Edit the file /System/Library/StartupItems/SystemTuning/SystemTuning and change the following values: sysctl -w kern.sysv.shmmax sysctl -w kern.sysv.shmmin sysctl -w kern.sysv.shmmni sysctl -w kern.sysv.shmseg sysctl -w kern.sysv.shmall (Without a Mac OSX box, I have no idea which is correct.) -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] RC2 will not make check on OSX 10.3
Neil, I posted to the apple site asking if anyone could recommend the 'correct' place to edit these settings. I don't think a change like this would survive a system update. But it was the only way I got the settings to 'take'. It deserves to be mentioned in the docs that this is necessary at least as far as 10.3.1 (osx). Ted --- Neil Conway <[EMAIL PROTECTED]> wrote: > Theodore Petrosky <[EMAIL PROTECTED]> writes: > > After about two hours of hunting pecking and > anything > > else I found where you control this in OSX 10.3 > > > > you must edit the /etc/rc file. > > > > > /System/Library/StartupItems/SystemTuning/SystemTuning > > does nothing > > Should we update the documentation's advice? At > present, it suggests: > > MacOS X > > Edit the file > /System/Library/StartupItems/SystemTuning/SystemTuning > and change the following values: > > sysctl -w kern.sysv.shmmax > sysctl -w kern.sysv.shmmin > sysctl -w kern.sysv.shmmni > sysctl -w kern.sysv.shmseg > sysctl -w kern.sysv.shmall > > (Without a Mac OSX box, I have no idea which is > correct.) > > -Neil > __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ---(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
[BUGS] Duplicate primary key record
Your name : Joel Jacobson
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel(R) Pentium(R) III
Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.21
PostgreSQL version (example: PostgreSQL-7.3.3): PostgreSQL-7.3.3
Compiler used (example: gcc 2.95.2) : gcc version 2.95.4 20011002
(Debian prerelease)
Please enter a FULL description of your problem:
I have simple table with a primary key.
Somehow two records with the SAME primary key has managed to get into the
table.
This should as far as I know be impossible.
I should mention that my Postgres daemon crashed two times today when I was
increasing its memory usage setting.
I guess this could have something to do with the problem.
Table
"public.userbalances"
Column | Type |
Modifiers
--+---+--
userid | integer | not null
balance | numeric(12,2) | not null
reservedbalance | numeric(12,2) | not null
modificationdate | integer | not null default (date_part('epoch'::text,
('now'::text)::timestamp(6) with time zone))::integer
Indexes: userbalances_pkey primary key btree (userid)
Foreign Key constraints: $1 FOREIGN KEY (userid) REFERENCES users(userid) ON
UPDATE NO ACTION ON DELETE NO ACTION
Triggers: autostamp
pbs=> select * from userbalances where userid = 1002024;
userid | balance | reservedbalance | modificationdate
-+--+-+--
1002024 | 1.00 | 154.02 | 1068947725
1002024 | 1.00 | 727.57 | 1068949964
(2 rows)
pbs=> UPDATE UserBalances SET Balance = 1, ReservedBalance=0 where userid =
1002024;
ERROR: Cannot insert a duplicate key into unique index userbalances_pkey
I can't understand how two rows with the same primary key can exist in this
table.
I will keep the table in this state if anyone would like to help debugging
this.
Best regards,
Joel Jacobson <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] RC2 will not make check on OSX 10.3
Neil Conway <[EMAIL PROTECTED]> writes:
> Should we update the documentation's advice?
Looks that way. On my 10.3 beta installation, the "SystemTuning" file
is present but it's just a stub ("exit 0"). The shmem sysctl calls have
been moved into /etc/rc. I presume this is deliberate, so we should
adjust our docs to match. I'll do so ...
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] RC2 will not make check on OSX 10.3
BTW,
I find it difficult to understand exactally what
reasonable values are.
Is it possible in the docs to explain a little what
these values should be. Or how to calculate them. I
felt totally in the dark. If I hadn't fallen across an
email on one of the sites that suggested values, I
think I wouldn't have succeeded. Luckily they worked.
There should be some way to recommend values.
Ted
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Should we update the documentation's advice?
>
> Looks that way. On my 10.3 beta installation, the
> "SystemTuning" file
> is present but it's just a stub ("exit 0"). The
> shmem sysctl calls have
> been moved into /etc/rc. I presume this is
> deliberate, so we should
> adjust our docs to match. I'll do so ...
>
> regards, tom lane
>
> ---(end of
> broadcast)---
> TIP 6: Have you searched our list archives?
>
>http://archives.postgresql.org
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
---(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: [BUGS] RC2 will not make check on OSX 10.3
Theodore Petrosky <[EMAIL PROTECTED]> writes: > I find it difficult to understand exactally what > reasonable values are. This page in the documentation includes a table that specifies "reasonable values" for all of the SysV IPC settings: http://candle.pha.pa.us/main/writings/pgsql/sgml/kernel-resources.html ISTM this is already documented. -Neil ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Duplicate primary key record
On Sun, 16 Nov 2003, Joel Jacobson wrote:
> Please enter a FULL description of your problem:
>
> I have simple table with a primary key.
> Somehow two records with the SAME primary key has managed to get into the
> table.
> This should as far as I know be impossible.
> I should mention that my Postgres daemon crashed two times today when I was
> increasing its memory usage setting.
> I guess this could have something to do with the problem.
>
> Table
> "public.userbalances"
> Column | Type |
> Modifiers
> --+---+--
> userid | integer | not null
> balance | numeric(12,2) | not null
> reservedbalance | numeric(12,2) | not null
> modificationdate | integer | not null default (date_part('epoch'::text,
> ('now'::text)::timestamp(6) with time zone))::integer
> Indexes: userbalances_pkey primary key btree (userid)
> Foreign Key constraints: $1 FOREIGN KEY (userid) REFERENCES users(userid) ON
> UPDATE NO ACTION ON DELETE NO ACTION
> Triggers: autostamp
>
> pbs=> select * from userbalances where userid = 1002024;
> userid | balance | reservedbalance | modificationdate
> -+--+-+--
> 1002024 | 1.00 | 154.02 | 1068947725
> 1002024 | 1.00 | 727.57 | 1068949964
> (2 rows)
Hmm, what does select oid,xmin,xmax,* where userid=1002024; give?
---(end of broadcast)---
TIP 8: explain analyze is your friend
