[BUGS] year and weeknumbers (proposal included)
hi, last year (2002) the date december 31st is in week 1 of 2003. it is not possible to get this out of a date-column using EXTRACT or to_char. to_char( '2002-12-31', 'WW' ) returns 1, and to_char( '2002-12-31', '' ) returns 2002 (as expected)! the format for retrieving the year with respect to week-numbering could be something like IY, IYY, IYYY, I. to_char( '2002-12-31', 'I' ) returns 2003. regards, Joost Helberg -- Joost Helberg Technisch Directeur Snow BV http://snow.nl Tel 0418-65 Fax 0418-653666 Voorzitter VOSN http://www.vosn.nl Tel 0418-653336 Fax 0418-653666 GPG PblKey fprnt= 738C 20AC A545 02AE 6F5D 5A9F D724 EB4B 2B10 150B ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Bug in LIKE operator processing
I've found that statement:
SELECT * FROM os WHERE 'FreeBSD 4.7-RC'
LIKE string_id; (one of string_id's is 'FreeBSD 4.7%')
doesn't work. No error is reported. It does work in Oracle,
so I think it's a standard SQL query.
Table is defined as:
host=> \d os
Table "os"
Column | Type | Modifiers
---+---+---
id| integer | not null default nextval('"os_id_seq"'::text)
name | character varying(32) |
major | integer |
minor | integer |
subrev| character(16) |
string_id | character(32) |
Unique keys: os_id_key
PostgreSQL version is 7.3.1
Is it non-implemented by design, or maybe I've overlooked something?
Thanks, /S
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] pgtcl combined with view with certain insert/update-rules => crash
Hi,
since 7.3 we observe repeatable crashes of the backend under certain
conditions.
If pgtcl-function executes an INSERT-command via spi-exec on a view with
an INSERT-rule which actually does not do an insert but a SELECT instead
the backend crashes when the rule-execution finished.
This does not happen if you do the same INSERT via psql-tool or from
within a pgsql-function via EXECUTE.
The same is true for UPDATE-command/rule.
Executing an INSERT as last statement of a rules fixes the problem.
postgresql 7.2 works fine.
Example:
CREATE VIEW a AS
SELECT f FROM b;
CREATE RULE r AS ON INSERT TO a DO INSTEAD (
SELECT xyz(NEW.f);
);
xyz is any stored procedure (i.e. written in pgsql).
(though I don't think it is important that a stored procedured is called
at all via the select).
CREATE FUNCTION t () RETURNS VOID AS '
spi_exec "INSERT INTO a (f) VALUES (''5'')"
' LANGUAGE 'pltcl';
Then calling t from psql i.e. leads to a crash.
If you change the rule r to
CREATE RULE r AS ON INSERT TO a DO INSTEAD (
SELECT xyz(NEW.f);
INSERT INTO dummy (bla) VALUES ('abcdefg');
);
(and table dummy exists of course)
then t works fine.
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
EDV
Leopoldstraße 15
80802 München
Tel: +49 89 38196 276
Fax: +49 89 38196 144
[EMAIL PROTECTED]
http://www.studentenwerk.mhn.de/
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] ECPG does not recognise typedefs
Postgre Version: 7.3 OS: Linux Mandrake 9.0 In a C-File I have included a header file which globaly defines some typedefs of variable types like following: typedef long MYLONG; When I write in the file the following definition: EXEC SQL begin declare section; static MYLONG sqlLongHostVar; EXEC SQL end declare section; the ecpg precompiler seems not to recognise this type although it is defined in the included header file. The following error occurs: ERROR: invalid datatype 'MYLONG' ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] [CHECKER] 9 potential out-of-bounds array access errors
Hi all,
We are a group of Stanford researchers, and we've recently developed a
tool that detects potential out-of-bounds array accesses and buffer
overruns. Here are 9 potential bugs we've found on postgresql 7.3.1.
We've been checking linux for a few years, and we're interested in
expanding to other system software as well. Let us know if you guys are
interested in bug reports like this. Confirmation and comments will be
appreciated.
Regards,
Yichen
Meta Compilation Group
http://metacomp.stanford.edu (little out of date tho)
# New errors.
#
-
[BUG] MAX_TIME_PRECISION defined to be 13 when HAVE_INT64_TIMESTAMP is
not defined
X [FALSE]
X [UNKNOWN]
X [BROKE]
X [SKIP]
/u2/yxie/postgresql-7.3.1/src/backend/utils/adt/date.c:682:AdjustTimeFor
Typmod: ERROR:BUFFER:682:682:Array bounds error (off >= len) [RANGE]
(TimeScales[typmod], len = 7, off = sym_905407, max(off-len) = 6)
}
#else
/* we have different truncation behavior depending on
sign */
if (*time >= 0)
{
Error --->
*time = (rint(((double) *time) *
TimeScales[typmod])
/ TimeScales[typmod]);
}
else
-
[BUG] "i" can go up to 13
X [FALSE]
X [UNKNOWN]
X [BROKE]
X [SKIP]
/u2/yxie/postgresql-7.3.1/src/backend/utils/mb/conversion_procs/euc_tw_a
nd_big5/big5.c:364:CNStoBIG5: ERROR:BUFFER:364:364:Array bounds error
(off >= len) (b2c3[i], len = 7, off = 7, min(off-len) = 0)
big5 = BinarySearchRange(cnsPlane2ToBig5Level2,
47, cns);
break;
case LC_CNS11643_3:
for (i = 0; i < sizeof(b2c3) / sizeof(unsigned
short); i++)
{
Error --->
if (b2c3[i][1] == cns)
return (b2c3[i][0]);
}
break;
-
[BUG] "i" can go up to 13
X [FALSE]
X [UNKNOWN]
X [BROKE]
X [SKIP]
/u2/yxie/postgresql-7.3.1/src/backend/utils/mb/conversion_procs/euc_tw_a
nd_big5/big5.c:371:CNStoBIG5: ERROR:BUFFER:371:371:Array bounds error
(off >= len) (b1c4[i], len = 4, off = 4, min(off-len) = 0)
}
break;
case LC_CNS11643_4:
for (i = 0; i < sizeof(b1c4) / sizeof(unsigned
short); i++)
{
Error --->
if (b1c4[i][1] == cns)
return (b1c4[i][0]);
}
default:
-
[BUG] is plpgsql_nDatums 0 here? also, sizeof (plpgsql_nDatums) =
2*sizeof(PLpgSQL_datum *)
X [FALSE]
X [UNKNOWN]
X [BROKE]
X [SKIP]
/u2/yxie/postgresql-7.3.1/src/pl/plpgsql/src/pl_comp.c:527:plpgsql_compi
le: ERROR:BUFFER:527:527:Dereferencing uninitialized pointer
(*(*function).datums + (PLpgSQL_datum**)(Oid)i * 4) evaluated in the
following state
for (i = 0; i < function->fn_nargs; i++)
function->fn_argvarnos[i] = arg_varnos[i];
function->ndatums = plpgsql_nDatums;
function->datums = malloc(sizeof(PLpgSQL_datum *) *
plpgsql_nDatums);
for (i = 0; i < plpgsql_nDatums; i++)
Error --->
function->datums[i] = plpgsql_Datums[i];
function->action = plpgsql_yylval.program;
ReleaseSysCache(procTup);
-
[BUG] does fe_setauthsvc abort the function? if not there's a
possibility of an overrun
X [FALSE]
X [UNKNOWN]
X [BROKE]
X [SKIP]
/u2/yxie/postgresql-7.3.1/src/interfaces/libpq/fe-auth.c:688:fe_getauths
vc: ERROR:BUFFER:688:688:Array bounds error (off >= len)
(authsvcs[pg_authsvc], len = 2, off = sym_3532626, min(off-len) = 0)
MsgType
fe_getauthsvc(char *PQerrormsg)
{
if (pg_authsvc < 0 || pg_authsvc >= n_authsvcs)
fe_setauthsvc(DEFAULT_CLIENT_AUTHSVC, PQerrormsg);
Error --->
return authsvcs[pg_authsvc].msgtype;
}
/*
-
[BUG] "i" can go up to 13
X [FALSE]
X [UNKNOWN]
X [BROKE]
X [SKIP]
/u2/yxie/postgresql-7.3.1/src/backend/utils/mb/conversion_procs/euc_tw_a
nd_big5/big5.c:325:BIG5toCNS: ERROR:BUFFER:325:325:Array bounds error
(off >= len) (b2c3[i], len = 7, off = 7, min(off-len) = 0)
else
{
/* level 2 */
for (i = 0; i < sizeof(b2c3) / sizeof(unsigned short);
i++)
{
Error --->
if (b2c3[i][0] == big5)
{
*lc = LC_CNS11643_3;
return (b2c3[i][1] | 0x8080U);
-
Re: [BUGS] Bug #883: explain analyze causes postgres to die
I included the code in the "example code" box. I'll include it again here.
If you need more info, just let me know.
I execute the command:
EXPLAIN ANALYZE INSERT INTO stubs(id, stub_id, nodecount, platform_id,
return_count)
SELECT I.id, A.stub_id, L.nodecount, P.platform_id, count(*)
FROM logdata L, id_lookup I, all_stubs A, platform P
WHERE lower(L.email) = lower(I.email)
AND L.stub_marks = A.stub_marks
AND L.os_type = P.os_type
AND L.cpu_type = P.cpu_type
AND L.version = P.version
GROUP BY I.id, A.stub_id, L.nodecount, P.platform_id;
and get back(from psql):
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset
The log shows:
2003-01-24 07:29:35 [36633] LOG: server process (pid 36657) was terminated
by signal 11
2003-01-24 07:29:35 [36633] LOG: terminating any other active server
processes
2003-01-24 07:29:35 [36633] LOG: all server processes terminated;
reinitializing shared memory and semaphores
2003-01-24 07:29:35 [3] LOG: connection received: host=[local]
2003-01-24 07:29:35 [3] FATAL: The database system is starting up
2003-01-24 07:29:35 [36665] LOG: database system was interrupted at
2003-01-24 07:23:52 GMT
2003-01-24 07:29:35 [36665] LOG: checkpoint record is at 26/2020EA78
2003-01-24 07:29:35 [36665] LOG: redo record is at 26/2020EA78; undo
record is at 0/0; shutdown TRUE
2003-01-24 07:29:35 [36665] LOG: next transaction id: 5758; next oid:
78509015
2003-01-24 07:29:35 [36665] LOG: database system was not properly shut
down; automatic recovery in progress
2003-01-24 07:29:35 [36665] LOG: ReadRecord: record with zero length at
26/2020EAB8
2003-01-24 07:29:35 [36665] LOG: redo is not required
2003-01-24 07:29:38 [36665] LOG: database system is ready
some info about the table:
Table "public.logdata"
Column | Type | Modifiers
+---+---
email | character varying(64) |
stub_marks | character varying(22) |
nodecount | bigint|
os_type| integer |
cpu_type | integer |
version| integer |
Indexes: logdata_cpu_version btree (cpu_type, "version"),
logdata_platform btree (os_type, cpu_type, "version")
Table "public.id_lookup"
Column | Type | Modifiers
--+---+---
email| character varying(64) |
id | integer |
stats_id | integer |
Indexes: idlookup_email_lower unique btree (lower(email)),
idlookup_id btree (id)
Table "public.all_stubs"
Column | Type | Modifiers
+---+---
stub_marks | character varying(22) | not null
stub_id| integer | not null default
nextval('"all_stubs_stub_id_seq"'::text)
project_id | smallint | not null
Indexes: all_stubs_pkey primary key btree (stub_id),
all_marks unique btree (stub_marks),
all_stubproject_id unique btree (stub_id, project_id)
Table "public.platform"
Column| Type | Modifiers
-+-+
---
platform_id | integer | not null default
nextval('public.platform_platform_id_seq'::text)
os_type | integer | not null
cpu_type| integer | not null
version | integer | not null
Indexes: platform_pkey primary key btree (platform_id),
platform_all btree (os_type, cpu_type, "version")
Table "public.stubs"
Column| Type | Modifiers
--+-+---
id | integer |
stub_id | integer |
nodecount| bigint |
platform_id | integer |
return_count | integer |
logdata:
count
--
21230697
(1 row)
id_lookup:
count
393614
(1 row)
all_stubs:
count
--
26243933
(1 row)
platform:
count
---
140
(1 row)
stubs:
count
---
0
(1 row)
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, January 24, 2003 12:28 AM
Subject: Re: [BUGS] Bug #883: explain analyze causes postgres to die
> [EMAIL PROTECTED] writes:
> > explain analyze causes postgres to die
>
> Can't do much with this, since you have not provided a complete test
> case.
>
> regards, tom lane
>
>
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] should be on MacOS X
I decided to build 7.3.1 on MacOS 10.2.3 with PAM support. % ./configure --with-pam --with-openssl ... configure: error: header file is required for PAM There is, however, a /usr/include/pam/pam_appl.h. So, I did a search/replace in configure and replaced it. % make ... gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o auth.o auth.c auth.c:45:31: security/pam_appl.h: No such file or directory ... make[3]: *** [auth.o] Error 1 So in auth.c, I did the same find/replace: #ifdef USE_PAM #include I added a file to /etc/pam.d for postgresql: % cat /etc/pam.d/postgresql auth required pam_nologin.so auth sufficient pam_securityserver.so auth sufficient pam_unix.so auth required pam_deny.so accountrequired pam_permit.so password required pam_deny.so sessionrequired pam_uwtmp.so And then it just worked: my user login for the machine got me into psql. - Aaron ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug in LIKE operator processing
On Mon, 27 Jan 2003, [iso-8859-2] ¯ak, S³awomir wrote: > I've found that statement: > > SELECT * FROM os WHERE 'FreeBSD 4.7-RC' > LIKE string_id; (one of string_id's is 'FreeBSD 4.7%') > string_id | character(32) | character(32) has space padding which is probably getting in your way. I'd suggest moving to varchar(32). ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] No migration path for MONEY
Bruce Momjian writes: > we need someone to get MONEY working as an extented NUMERIC type. How would the new "money" be different from "numeric"? If we have "money", should we have "length", "mass", and "temperature"? I think not. Just let the money type die and that's it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #882: Cannot manually log in to database.
Here's a little more detail as to how this socket file was getting deleted:
On the system I'm using, if you attempt to start postmaster when an instance
of it is already running, the socket file gets deleted. It was discovered
that upon bootup of the system, the postgres startup script was being
executed twice in the /sbin/rc3.d directory, and this was causing the socket
file to get deleted. It wasn't a cron job.
Ben Kinsey
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 24, 2003 11:04 AM
To: Giles Lean
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [BUGS] Bug #882: Cannot manually log in to database.
Giles Lean <[EMAIL PROTECTED]> writes:
> Either teach your /tmp cleaner not to clean out the socket files as
> Tom Lane suggested, or arrange to update the socket timestamps. I
> think it's easier to just keep updating the timestamps -- then I don't
> have to educate each new system administrator.
> utimes("/tmp/.s.PGSQL.5432", (const struct timeval *) 0);
Hm, do you think that's portable?
There is already code in the postmaster to touch the socket lock file every
few minutes, so as to keep tmp-cleaners from zapping it. (Or at least there
once was; I can't find it right now.) If we could do the same for the
socket file it'd be really nice. But I didn't think there was any portable
way to update the mod timestamp on a socket.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug in LIKE operator processing
=?iso-8859-2?Q?=AFak=2C_S=B3awomir?= <[EMAIL PROTECTED]> writes: > I've found that statement: > SELECT * FROM os WHERE 'FreeBSD 4.7-RC' > LIKE string_id; (one of string_id's is 'FreeBSD 4.7%') > doesn't work. No error is reported. It does work in Oracle, It'd probably work in Postgres too, if you'd used varchar(n) rather than char(n) for string_id. As is, the trailing spaces in string_id are considered significant. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] pgtcl combined with view with certain insert/update-rules => crash
Wolfgang Walter <[EMAIL PROTECTED]> writes:
> since 7.3 we observe repeatable crashes of the backend under certain
> conditions.
I can't reproduce your problem... using 7.3 branch here, I did this:
bug=# create table b (f int);
CREATE TABLE
bug=# CREATE VIEW a AS SELECT f FROM b;
CREATE VIEW
bug=# create function xyz(int) returns int as '
bug'# begin
bug'# return $1;
bug'# end' language plpgsql;
CREATE FUNCTION
bug=# select xyz(33);
xyz
-
33
(1 row)
bug=# CREATE RULE r AS ON INSERT TO a DO INSTEAD (
bug(# SELECT xyz(NEW.f);
bug(# );
CREATE RULE
bug=# CREATE FUNCTION t () RETURNS VOID AS '
bug'# spi_exec "INSERT INTO a (f) VALUES (''5'')"
bug'# ' LANGUAGE 'pltcl';
CREATE FUNCTION
bug=# select t();
t
---
(1 row)
bug=#
Perhaps there is a platform-specific issue, but one thing I'd advise
checking first is whether you are linking to the 7.3 versions of
pltcl.so and plpgsql.so. If you've got absolute paths in the CREATE
FUNCTION commands for the language handlers, you might be pulling in
old versions of those handlers, leading to all kinds of weird behavior.
Preferably the pg_proc entries should look like
bug=# select proname,prosrc,probin from pg_proc where proname like '%_handler';
proname|prosrc| probin
--+--+-
pltcl_call_handler | pltcl_call_handler | $libdir/pltcl
plpgsql_call_handler | plpgsql_call_handler | $libdir/plpgsql
(2 rows)
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] [CHECKER] 9 potential out-of-bounds array access errors
"Yichen Xie" <[EMAIL PROTECTED]> writes: > We are a group of Stanford researchers, and we've recently developed a > tool that detects potential out-of-bounds array accesses and buffer > overruns. Here are 9 potential bugs we've found on postgresql 7.3.1. > We've been checking linux for a few years, and we're interested in > expanding to other system software as well. Let us know if you guys are > interested in bug reports like this. This looks like great stuff --- I haven't read through all of them, but at least the first couple look like genuine bugs. I'm a little suspicious of the tool's coverage though. For example, in src/backend/utils/mb/conversion_procs/euc_tw_and_big5/big5.c, why'd it flag only one of the two loops that use the same incorrect limit for scanning b1c4[][] ? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] [CHECKER] 9 potential out-of-bounds array access errors
Yichen Xie <[EMAIL PROTECTED]> writes: > Both are flagged though--the other one's 85 lines down in the bug report.. > ;) I probably should've sorted the list by location to minimize confusion. That's okay, I probably should've read the whole mail before commenting ;-) I'm confused by the entry flagging pl_comp.c:527: [BUG] is plpgsql_nDatums 0 here? also, sizeof (plpgsql_nDatums) = 2*sizeof(PLpgSQL_datum *) Is the thing concerned because malloc(0) may yield NULL on some platforms? If so, should I object that it ought to be smart enough to know the loop won't execute in that case? Or am I missing something? Also, I don't understand your comment about the sizeof() relationship. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] [CHECKER] 9 potential out-of-bounds array access errors
> We are a group of Stanford researchers, and we've recently developed a > tool that detects potential out-of-bounds array accesses and buffer > overruns. Here are 9 potential bugs we've found on postgresql 7.3.1. > We've been checking linux for a few years, and we're interested in > expanding to other system software as well. Let us know if you guys are > interested in bug reports like this. Confirmation and comments will be > appreciated. Thanks. I have confirmed that at least following reports are correct. Will fix them. > [BUG] "i" can go up to 13 > X [FALSE] > X [UNKNOWN] > X [BROKE] > X [SKIP] > /u2/yxie/postgresql-7.3.1/src/backend/utils/mb/conversion_procs/euc_tw_a > nd_big5/big5.c:364:CNStoBIG5: ERROR:BUFFER:364:364:Array bounds error v > [BUG] "i" can go up to 13 > X [FALSE] > X [UNKNOWN] > X [BROKE] > X [SKIP] > /u2/yxie/postgresql-7.3.1/src/backend/utils/mb/conversion_procs/euc_tw_a > nd_big5/big5.c:371:CNStoBIG5: ERROR:BUFFER:371:371:Array bounds error -- Tatsuo Ishii ---(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] [CHECKER] 9 potential out-of-bounds array access errors
"Yichen Xie" <[EMAIL PROTECTED]> writes:
> We are a group of Stanford researchers, and we've recently developed a
> tool that detects potential out-of-bounds array accesses and buffer
> overruns. Here are 9 potential bugs we've found on postgresql 7.3.1.
Here's a status report:
> [BUG] MAX_TIME_PRECISION defined to be 13 when HAVE_INT64_TIMESTAMP is
> not defined
> /u2/yxie/postgresql-7.3.1/src/backend/utils/adt/date.c:682:AdjustTimeFor
> Typmod: ERROR:BUFFER:682:682:Array bounds error (off >= len) [RANGE]
Real bug introduced in multiple-time-storage-format changes in 7.3.
Fixed in current and 7.3 branch.
> [BUG] "i" can go up to 13
> /u2/yxie/postgresql-7.3.1/src/backend/utils/mb/conversion_procs/euc_tw_a
> nd_big5/big5.c:364:CNStoBIG5: ERROR:BUFFER:364:364:Array bounds error
Real bug, code is new in 7.3. Fixed in current and 7.3 branch.
> [BUG] "i" can go up to 13
> /u2/yxie/postgresql-7.3.1/src/backend/utils/mb/conversion_procs/euc_tw_a
> nd_big5/big5.c:371:CNStoBIG5: ERROR:BUFFER:371:371:Array bounds error
As above.
> [BUG] is plpgsql_nDatums 0 here? also, sizeof (plpgsql_nDatums) =
> 2*sizeof(PLpgSQL_datum *)
> /u2/yxie/postgresql-7.3.1/src/pl/plpgsql/src/pl_comp.c:527:plpgsql_compi
> le: ERROR:BUFFER:527:527:Dereferencing uninitialized pointer
Doesn't seem to be a bug, unless I'm missing something. Checker
apparently fooled by globalness of variable?
> [BUG] does fe_setauthsvc abort the function? if not there's a
> possibility of an overrun
> /u2/yxie/postgresql-7.3.1/src/interfaces/libpq/fe-auth.c:688:fe_getauths
> vc: ERROR:BUFFER:688:688:Array bounds error (off >= len)
Potential bug; could only trigger if compile-time-constant
DEFAULT_CLIENT_AUTHSVC has incorrect value. I wouldn't expect the
checker to realize that, though (it'd take cross-procedural analysis).
Fixed in CVS head in case of future mistakes, but not back-patched.
> [BUG] "i" can go up to 13
> /u2/yxie/postgresql-7.3.1/src/backend/utils/mb/conversion_procs/euc_tw_a
> nd_big5/big5.c:325:BIG5toCNS: ERROR:BUFFER:325:325:Array bounds error
See above.
> [BUG] MAX_TIME_PRECISION is 13
> /u2/yxie/postgresql-7.3.1/src/backend/utils/adt/date.c:691:AdjustTimeFor
> Typmod: ERROR:BUFFER:691:691:Array bounds error (off >= len) [RANGE]
See above.
> [BUG]
> /u2/yxie/postgresql-7.3.1/src/backend/utils/mb/conversion_procs/euc_tw_a
> nd_big5/big5.c:304:BIG5toCNS: ERROR:BUFFER:304:304:Array bounds error
See above.
> [BUG] ndim can be 0...
> /u2/yxie/postgresql-7.3.1/src/backend/utils/adt/arrayfuncs.c:352:ArrayCo
> unt: ERROR:BUFFER:352:352:Array bounds error (off < 0) (temp[ndim - 1],
This cannot happen in current sources because ArrayCount is only invoked
on strings beginning with '{'. Still, it seems like an accident waiting
to happen. I've modified CVS tip so that ndim is initialized to 1, not
0, to forestall any future problem.
Thanks for the report!
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] No migration path for MONEY
Peter Eisentraut <[EMAIL PROTECTED]> writes: > How would the new "money" be different from "numeric"? [ temporarily re-dons currency-trader hat... ] What would actually be useful is a money type that carries along an indication of which currency the amount is expressed in (not per-column as Bruce naively suggested, but right in the datum). This would allow conversions to be performed between different currencies, as well as allowing the correct decoration to be provided on output. > If we have "money", should we have "length", "mass", and > "temperature"? I think not. Physicists have found use for numeric objects that carry along an indication of the units they're in --- in other words, not "length" etc, but a generic "measurement" type that might tag its value as "meters" or "kilograms" or "furlongs per fortnight". I'm not eager to go and write such a datatype right now, but if someone wanted to do the work I'd be in favor of adopting one. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] Bug with usernames that are only numbers
Hello people, I am sorry for bothering, but lately I ran into a bug, and it took me really some time to find it out. However the problem is this: It is possible to create a user of which the Username consists only of numbers. (sorry for this long and descriptive english) e.g.: CREATE USER "12345" WITH ENCRYPTED PASSWORD 'ohjoy'; However, this user will not be able to connect. At least not with 'psql', but I had trouble trying out with PHP as well, so I reckon this happens all the time. neither of these options will work: psql -U 12345 psql -U "12345" psql -U '12345' Of course there are workarounds, but it is not right that I can create users that cannot connect... Michiel ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] [CHECKER] 9 potential out-of-bounds array access errors
Both are flagged though--the other one's 85 lines down in the bug report.. ;) I probably should've sorted the list by location to minimize confusion. Thanks for the feedback! -Yichen On Tue, 28 Jan 2003, Tom Lane wrote: > This looks like great stuff --- I haven't read through all of them, but > at least the first couple look like genuine bugs. I'm a little > suspicious of the tool's coverage though. For example, in > src/backend/utils/mb/conversion_procs/euc_tw_and_big5/big5.c, > why'd it flag only one of the two loops that use the same incorrect > limit for scanning b1c4[][] ? > > regards, tom lane > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] [CHECKER] 9 potential out-of-bounds array access errors
I think it's 'coz the only assignment to "plpgsql_nDatums" the checker could find is on line 176, without realizing plpgsql_nDatums is actually a global variable and could be changed anywhere... We'll rule out cases like this in the future. Thanks for letting us know. --yichen On Tue, 28 Jan 2003, Tom Lane wrote: > I'm confused by the entry flagging pl_comp.c:527: > > [BUG] is plpgsql_nDatums 0 here? also, sizeof (plpgsql_nDatums) = > 2*sizeof(PLpgSQL_datum *) > > Is the thing concerned because malloc(0) may yield NULL on some > platforms? If so, should I object that it ought to be smart enough to > know the loop won't execute in that case? Or am I missing something? > Also, I don't understand your comment about the sizeof() relationship. > > regards, tom lane > ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] [CHECKER] 9 potential out-of-bounds array access errors
Tatsuo Ishii <[EMAIL PROTECTED]> writes: > Thanks. I have confirmed that at least following reports are > correct. Will fix them. I already committed fixes in HEAD and 7.3 branch. I wanted to ask you if this might explain some of the odd reports we've gotten about conversion problems? I can't recall right now if any of them had to do with big5 data ... 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
Re: [BUGS] [CHECKER] 9 potential out-of-bounds array access errors
> Tatsuo Ishii <[EMAIL PROTECTED]> writes: > > Thanks. I have confirmed that at least following reports are > > correct. Will fix them. > > I already committed fixes in HEAD and 7.3 branch. Thanks. > I wanted to ask you if this might explain some of the odd reports we've > gotten about conversion problems? I can't recall right now if any of > them had to do with big5 data ... I don't think so. It seems most of them were caused by bad input text strings(incorrect EUC_TW or so). -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #883: explain analyze causes postgres to die
"Chris Hodson" <[EMAIL PROTECTED]> writes: > I included the code in the "example code" box. I'll include it again here. > If you need more info, just let me know. I'm still not able to duplicate this. Perhaps you could provide a stack trace? (Preferably from a backend built with --enable-debug.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
