[BUGS] int4, int8, real ....division...
pgsql-7.4.2 I think it's not a bug, just interesting results: SELECT 9223372036854775807/(365*1000) ; result: -14300526699 wrong SELECT ( 9223372036854775807/365 )/1000 ; result: 2526951242 good SELECT ( 9223372036854775807::real /(365*1000) ) ; result: -14300526699,6589 wrong SELECT ( 9223372036854775807 /(365*1000)::real ) ; result: -14300526699,6589 wrong SELECT ( 9223372036854775807 /(365*1000)::real ) ; result: -14300526699,6589 wrong SELECT ( 9223372036854775807/(365*1000::real) ) ; result: 2526951242,97391 good SELECT ( 9223372036854775807/(365::real*1000) ) ; result: 2526951242,97391 good REASON IS: SELECT 365*1000 ; result: -644967296 wrong but SELECT 365*1000::int8 ; result: 365000 good If this operation embended in complex expression, then very difficult to find the reason of computation error. This misstake comes only after the border of int4 and int8. - Gyenese Pál Attila számítástechnikai vezető MEDIAGNOST KFT. 1106 Fehér út 10 Tel.: 431.87.74 Fax.: 265.20.73 ---(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] int4, int8, real ....division...
"=?iso-8859-2?Q?Gyenese_P=E1l_Attila?=" <[EMAIL PROTECTED]> writes: > REASON IS: > SELECT 365*1000 ; > result: -644967296 > wrong This isn't a division problem --- the difficulty is there's no check for overflow in int4 multiplication. (Nor in any of the other integer arithmetic operations, for that matter.) It'd be nice if C made it easier to detect integer overflow :-( ... AFAIK, testing this would make those subroutines many times slower, which is pretty annoying when the hardware already knows whether the result overflowed or not. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] BUG #1145: silent REVOKE failures
Dear Bruce, > > > Well, if I issue a "REVOKE" and the rights are not revoked and could never > > > have been because I have no right to issue such statement on the object, I > > > tend to call this deep absence of success a "failure". > > > > > If I do the very opposite GRANT, I have a clear "permission denied". > > > > Oh, I thought you were complaining that revoking rights not previously > > granted should be an error. I agree with the above; in fact it's a > > duplicate of a previous complaint. > > Did we resolve this? Is it a TODO? No? No? There has been a lot of off-line discussion about how to interpret the standard on this point. I'm not even sure we perfectly agreed in the end, although our understanding of the issues improved a lot through the discussion. As a summary, it is pretty subtle, especially as the standard wording is contrived, and postgres does not do what should be done in a lot of cases. There are also actual "security" bugs. For the TODO, I would suggest something general: - fix grant/revoke wrt SQL standard, validate errors, warnings and successes. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] postgres crashes
Hello I've been installed Postgres 7.4.2 on FreeBSD system and when load average grow up i've error in postgres like this: ERROR: permission denied for function varchar ERROR: permission denied for function varchar and then postgres crashes. LOG: server process (PID 9787) was terminated by signal 11 LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. LOG: all server processes terminated; reinitializing FATAL: the database system is starting up This error occurs on Postgres version 7.4.x . This error doesn't occur on Postgres version 7.3.x but are much more slower (even 300% slower) then version 7.4.x. and that's why 7.4.x is necessary. Postgres configuration: connection 50 shared_buffers 1000 In FreeBSD kernel i've increased SEMMNS and SEMMNI parameters Can anyone help me, and tell me where is the source of problem: postgres or FreeBSD or both? Thanks in advance. Adam Kempa ---(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] BUG #1154: no python interface anymore
Dear support, In the unfortuenate case that the pygreSQL directory won't be re-added in future PostgreSQL versions, then, at the least, configuring PostgreSQL with the --with-python option should give some kind of error/warning when the directory is empty (and also an instruction of what to do). Kind regards, Yruhn -- Original Message -- From: Tom Lane <[EMAIL PROTECTED]> Date: Fri, 14 May 2004 08:21:28 -0400 >Peter Eisentraut <[EMAIL PROTECTED]> writes: >> Yes. It was supposed to move to http://www.pygresql.org, but that web site >> doesn't seem to exist anymore. > >Hmm. whois shows the pygresql.org domain as PENDING DELETE, but the >reason is not apparent since it seems to be paid up through 2005. >D'Arcy, what's up? > > regards, tom lane > Sent via the WebMail system at xdh.nl ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1154: no python interface anymore
On Fri, 14 May 2004 08:21:28 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Yes. It was supposed to move to http://www.pygresql.org, but that > > web site doesn't seem to exist anymore. > > Hmm. whois shows the pygresql.org domain as PENDING DELETE, but the > reason is not apparent since it seems to be paid up through 2005. > D'Arcy, what's up? Sorry to take so long to answer. OpenSRS, our domain registrar, messed up. We were on automatic renewal which occurred but they forgot to send the money to the central registry and so we wound up with that strange combo above. We got them straightened out and it should be OK now. Now, if I can just figure out why our secondary isn't picking up the zone I will be fine. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(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] postgres crashes
Adam Kempa <[EMAIL PROTECTED]> writes: > I've been installed Postgres 7.4.2 on FreeBSD system and when load > average grow up i've error in postgres like this: >ERROR: permission denied for function varchar >ERROR: permission denied for function varchar > and then postgres crashes. >LOG: server process (PID 9787) was terminated by signal 11 I think you've got hardware problems. Specifically, this sounds like it could be bad RAM in an address range that doesn't get used until the system gets sufficiently loaded. memtest86 is a widely-recommended test program for finding bad RAM ... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] LATIN2 'bssz' and 'bszsz' fails on unique index
Hello,
If you use Latin2 encoding, you can not have 'bssz' and 'bszsz' in an
unique column in the same time.
Is this a known bug? Do you have any solution? (I use Latin2 encoding,
because I want to order by names, which contains accent characters.)
[EMAIL PROTECTED]:~> psql template1
Welcome to psql 7.4.2, the PostgreSQL interactive terminal.
template1=# CREATE DATABASE test WITH ENCODING = 'LATIN2';
CREATE DATABASE
template1=# \c test
You are now connected to database "test".
test=# CREATE TABLE test (name character varying (128) UNIQUE NOT NULL);
NOTICE: CREATE TABLE / UNIQUE will create implicit index
"test_name_key" for table "test"
CREATE TABLE
test=# INSERT INTO test (name) VALUES ('bssz');
INSERT 17798 1
test=# INSERT INTO test (name) VALUES ('bszsz');
ERROR: duplicate key violates unique constraint "test_name_key"
test=#
I am running Debian Sid i386 with 2.6.6 kernel, libc6 2.3.2.ds1-12,
locales 2.3.2.ds1-12, postgresql 7.4.2-4 . Locale for postgres user is
"POSIX", locale for the psql client is "hu_HU". Both client and server
encoding for the above connections was Latin2.
Thanks,
d43m0n.
PS: Please CC me, I am not subscribed to the list.
--
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] LATIN2 'bssz' and 'bszsz' fails on unique index
=?ISO-8859-2?Q?S=FCn?= <[EMAIL PROTECTED]> writes: > If you use Latin2 encoding, you can not have 'bssz' and 'bszsz' in an > unique column in the same time. AFAICS this means that your locale definition considers these strings equal. It is possible that the real problem comes from using an encoding that's not compatible with what the locale setting expects. Locales generally do require a specific character set encoding, though this is poorly documented :-( 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
