[BUGS] BUG #1608: integer negative limit in plpgsql function arguments
The following bug has been logged online: Bug reference: 1608 Logged by: Paul Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.2 Operating system: Gentoo and Fedora Core 3 Description:integer negative limit in plpgsql function arguments Details: The script below best sums up the problem (and the work around). The question is: should I use that for all integers being put into a function? 8< create table test ( test_id integer ); insert into test (test_id) values (-2147483648); create function print_test_id (integer) returns integer AS ' DECLARE tmp ALIAS FOR $1; val integer; BEGIN select into val test_id from test where test_id = tmp; return val; END; ' LANGUAGE plpgsql; -- this doesn't work (and I think it should!) SELECT print_test_id(-2147483648); -- this is the workaround SELECT print_test_id((-2147483648)::int); >8 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1605: Is this a bug of PostgreSQL?Or, is the parameter of Windows set?
It is Sawai.
I am sorry. There is a correction.
>The following server logs are output when the program that gets a large
>amount of Connection with PostgreSQL8.0.1/8.0.2 is operated, and PostgreSQL
>stops. Concretely, all the postgres processes and the postmaster processes
>stop.
Only the postmaster process ends.
The postgres process in the state of gettting the connection
is the state as it is.
--
It is information on the supplementation.
-PostgreSQL8.0.1/8.0.2 can both get 500 connections in the Linux environment
without
trouble.
-It did not solve it though"/3GB/Userva=2900" and option were added to
"boot.ini".
-The same situation was able to be reproduced by changing registry
information though the connection of another problem was not able to be
acquired in the environment of Windows XP.
HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentContrilSet -> Control -> Session
Manager -> SubSystem
(default)Windows SharedSection=1024,3072,512
(After it changes)Windows SharedSection=1024,3072,1024
-Original Message-
From: OSD 澤井 健(技術開発)
Sent: Monday, April 18, 2005 2:17 PM
To: pgsql-bugs@postgresql.org
Subject: BUG #1605: Is this a bug of PostgreSQL?Or, is the parameter of
Windows set?
The following bug has been logged online:
Bug reference: 1605
Logged by: Takehsi Sawai
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1/8.0.2
Operating system: Windows 2003 Server
Description:Is this a bug of PostgreSQL?Or, is the parameter of
Windows set?
Details:
Hi.
I'm from Japan. Sorry for my English.
The following server logs are output when the program that gets a large
amount of Connection with PostgreSQL8.0.1/8.0.2 is operated, and PostgreSQL
stops. Concretely, all the postgres processes and the postmaster processes
stop.
It reproduces without fail without fail, and, every time, it fails because
of
the acquisition of the connection of piece 490.
PostgreSQL Server Log
(DEBUG5)
>2005-04-13 08:14:43 FATAL: XX000: could not create sigchld waiter thread:
error code 8
>2005-04-13 08:14:43 LOCATION: internal_forkexec, postmaster.c:3143
---
The environment of the machine and the setting of PostgreSQL are as follows.
spec
CPU:Xeon 2.4GHz x 1
Mem:2GB
HD:73GB？2(RAID-1)
OS:Windows Server 2003(Standard/Enterprise)
---
postgresql.conf
listen_addresses='*'
max_connections=1000
shared_buffer=2000
---
>From log Function CreateThread, and to failure, and error code 8=
ERROR_NOT_ENOUGH_MEMORY native of win32
However, the memory that can be used seems to have room enough from
Windows task manager -> performance.
Is this a bug of PostgreSQL?Or, is the parameter of Windows set?
postmaster.c
(line 3138 - 3144)
> waiterThread = CreateThread(NULL, 64 * 1024, win32_sigchld_waiter,
> (LPVOID)
childHandleCopy, 0, NULL);
> if (!waiterThread)
> ereport(FATAL,
> (errmsg_internal("could not create sigchld waiter thread:
error code
%d",
> (int)
GetLastError(;
---
Link MSDN
CreateThread
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas
e/createthread.asp
ERROR CODE
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/
system_error_codes__0-499_.asp
---
Program for test as follows
Simple Java program
(JDBC Driver : postgresql-8.0-310.jdbc3.jar)
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.ArrayList;
import java.util.Iterator;
public class ConnectionCheck {
public static void main(String[] args) {
String driver = "org.postgresql.Driver";
String url = "jdbc:postgresql://10.8.255.131:5432/eval-pg";
String user = "eval-pg";
String password = "kayabacho";
Statement stmt = null;
PreparedStatement pstmt = null;
ResultSet rs = null;
Connection con = null;
int status = 1;
int count = 0;
int maxConnection = 1
Re: [BUGS] BUG #1608: integer negative limit in plpgsql function arguments
"Paul" <[EMAIL PROTECTED]> writes: > -- this doesn't work (and I think it should!) > SELECT print_test_id(-2147483648); "2147483648" isn't an integer constant; it's int8, and therefore so is the result of the minus operator. Sorry, this isn't going to change. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] BUG #1609: Bug in interval datatype for 64 Bit timestamps
The following bug has been logged online: Bug reference: 1609 Logged by: Oliver Siegmar Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.2 Operating system: Linux Description:Bug in interval datatype for 64 Bit timestamps Details: Postgres compiled with --enable-integer-datetimes has a bug in interval datatype representation - select '10.10 secs ago'::interval; interval --- @ 10.-10 secs ago (1 row) Without --enable-integer-datetimes - interval -- @ 10.10 secs ago (1 row) Please CC me, because I'm not on the list. Oliver ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1609: Bug in interval datatype for 64 Bit timestamps
"Oliver Siegmar" <[EMAIL PROTECTED]> writes: > select '10.10 secs ago'::interval; > interval > --- > @ 10.-10 secs ago > (1 row) What datestyle are you using? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1609: Bug in interval datatype for 64 Bit timestamps
Oliver Siegmar <[EMAIL PROTECTED]> writes: >> What datestyle are you using? > Non-ISO (Postgres in that case), but the handling for non-ISO is all the same > in interval.c ... Yeah, I just confirmed here that it's broken the same way in all three non-ISO datestyles. Will look into a fix later today. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1609: Bug in interval datatype for 64 Bit timestamps
I've applied this patch.
regards, tom lane
Index: datetime.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/datetime.c,v
retrieving revision 1.137
diff -c -r1.137 datetime.c
*** datetime.c 11 Jan 2005 18:33:45 - 1.137
--- datetime.c 20 Apr 2005 17:09:57 -
***
*** 3883,3899
/* fractional seconds? */
if (fsec != 0)
{
#ifdef HAVE_INT64_TIMESTAMP
if (is_before || ((!is_nonzero) && (tm->tm_sec
< 0)))
tm->tm_sec = -tm->tm_sec;
sprintf(cp, "%s%d.%02d secs", (is_nonzero ? " "
: ""),
! tm->tm_sec, (((int) fsec) /
1));
cp += strlen(cp);
- if (!is_nonzero)
- is_before = (fsec < 0);
#else
- fsec_t sec;
-
fsec += tm->tm_sec;
sec = fsec;
if (is_before || ((!is_nonzero) && (fsec < 0)))
--- 3883,3907
/* fractional seconds? */
if (fsec != 0)
{
+ fsec_t sec;
+
#ifdef HAVE_INT64_TIMESTAMP
+ sec = fsec;
if (is_before || ((!is_nonzero) && (tm->tm_sec
< 0)))
+ {
tm->tm_sec = -tm->tm_sec;
+ sec = -sec;
+ is_before = TRUE;
+ }
+ else if ((!is_nonzero) && (tm->tm_sec == 0) &&
(fsec < 0))
+ {
+ sec = -sec;
+ is_before = TRUE;
+ }
sprintf(cp, "%s%d.%02d secs", (is_nonzero ? " "
: ""),
! tm->tm_sec, (((int) sec) /
1));
cp += strlen(cp);
#else
fsec += tm->tm_sec;
sec = fsec;
if (is_before || ((!is_nonzero) && (fsec < 0)))
***
*** 3905,3913
is_before = (fsec < 0);
#endif
is_nonzero = TRUE;
-
- /* otherwise, integer seconds only? */
}
else if (tm->tm_sec != 0)
{
int sec = tm->tm_sec;
--- 3913,3920
is_before = (fsec < 0);
#endif
is_nonzero = TRUE;
}
+ /* otherwise, integer seconds only? */
else if (tm->tm_sec != 0)
{
int sec = tm->tm_sec;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1609: Bug in interval datatype for 64 Bit timestamps
Hi Tom, On Wednesday 20 April 2005 17:57, Tom Lane wrote: > "Oliver Siegmar" <[EMAIL PROTECTED]> writes: > > select '10.10 secs ago'::interval; > > > > interval > > --- > > @ 10.-10 secs ago > > (1 row) > > What datestyle are you using? Non-ISO (Postgres in that case), but the handling for non-ISO is all the same in interval.c ... ISO works fine - interval -- -00:00:10.10 (1 row) Oliver ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1608: integer negative limit in plpgsql function arguments
Paul Edwards <[EMAIL PROTECTED]> writes: > Also, just as an experiment I tried the minimum limit for bigint (see > attached file). It seems that I do not need to cast for negative limit > which is inconsistent since 9223372036854775808 is not a bigint (when > -9223372036854775808 is). Therefore the type wasn't necessarily > determined before the unary operator. Really? [ tries it ... then reads some code ... ] You're right, we do cheat a little on negative numeric constants --- I had forgotten about the doNegate() hack in gram.y. We could conceivably fix it to cheat some more. Specifically it looks like make_const() in parse_node.c could check for the possibility that a T_Float fits in INT4 --- which would happen only for the case of -2147483648, since any smaller absolute value would have been T_Integer to start with. This also brings up the thought that maybe the T_Integer case should create an INT2 rather than INT4 Const if the value is small enough. I'm fairly hesitant to do that though because it would be a significant change in behavior, possibly breaking apps that don't have a problem now. (IIRC we experimented with such a change some years back and saw widespread failures in the regression tests, for example.) However changing the behavior only for -2147483648 seems like a relatively safe thing to do. Thoughts, objections anyone? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
