Re: [HACKERS] Need NetBSD thread tester
quote who=Bruce Momjian Wow, that is strange. Someone else told me NetBSD supports threads, and doesn't need any special compile flags, but of course, it has to have pthread.h to support threads. NetBSD 1.6.1 is very current, so it isn't an old OS. NetBSD-1.6.1 doesn't have native thread. NetBSD-current has it though. Thomas T. Thai ---(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: [HACKERS] Deadlock while doing VACUUM??
Even dropping the table and all of its indexes and recreating it does nothing to solve this problem, so I don't have any reason to suspect corruption of the table itself. Corruption elsewhere is a possibility, I suppose, but I haven't noticed any strangeness elsewhere. This sounds very similiar to problems I was having under the thread: Re: [HACKERS] BUG: Vacuum Analyze - datumGetSize: Invalid typLen 0 Dropping the table, indexes, and recreating it didn't help me either. I had to drop the database! What kind of platform are you on? 64-bit? I've noticed that 7.4-snapshot fixed a huge amount of bugs, but the vacuum analyze bug is still there. -- Thomas ---(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
[HACKERS] 7.4-snapshot regression: ERROR: datumGetSize: Invalid typLen 0
After experiencing so many problems with 7.3.2, I decided to test 7.4-snapshot. It failed only on one test, instead of 17. NetBSD-1.6 / Alpha (64-bit) Postgresql-7.4-snapshot-2003-03-24 The error I'm getting is: ! ERROR: datumGetSize: Invalid typLen 0 That error caused many problems in 7.3.2. I sent an email about this but it must be stuck in the queue because it had an attachment of 234k. --- *** ./expected/opr_sanity.out Tue Jan 28 16:13:41 2003 --- ./results/opr_sanity.outWed Mar 26 22:08:17 2003 *** *** 46,55 p1.proname = p2.proname AND p1.pronargs = p2.pronargs AND p1.proargtypes = p2.proargtypes; ! oid | proname | oid | proname ! -+-+-+- ! (0 rows) ! -- Considering only built-in procs (prolang = 12), look for multiple uses -- of the same internal function (ie, matching prosrc fields). It's OK to -- have several entries with different pronames for the same internal function, --- 46,52 p1.proname = p2.proname AND p1.pronargs = p2.pronargs AND p1.proargtypes = p2.proargtypes; ! ERROR: datumGetSize: Invalid typLen 0 -- Considering only built-in procs (prolang = 12), look for multiple uses -- of the same internal function (ie, matching prosrc fields). It's OK to -- have several entries with different pronames for the same internal function, *** *** 276,285 p1.oprkind = p2.oprkind AND p1.oprleft = p2.oprleft AND p1.oprright = p2.oprright; ! oid | oprcode | oid | oprcode ! -+-+-+- ! (0 rows) ! -- Look for commutative operators that don't commute. -- DEFINITIONAL NOTE: If A.oprcom = B, then x A y has the same result as y B x. -- We expect that B will always say that B.oprcom = A as well; that's not --- 273,279 p1.oprkind = p2.oprkind AND p1.oprleft = p2.oprleft AND p1.oprright = p2.oprright; ! ERROR: datumGetSize: Invalid typLen 0 -- Look for commutative operators that don't commute. -- DEFINITIONAL NOTE: If A.oprcom = B, then x A y has the same result as y B x. -- We expect that B will always say that B.oprcom = A as well; that's not == -- Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] BUG: Vacuum Analyze - datumGetSize: Invalid typLen 0
I just tested this on 7.4-snapshot-2003-03-24 and the same error occurred.
The one regression test (opr_sanity) in 7.4-snapshot that failed also had
this error.
ERROR: datumGetSize: Invalid typLen 0
System: NetBSD / Alpha 1.6 (64 bit)
Postgresql 7.3.2
Bug: after vacuum analyze, I'm unable to do a simple select. Instead I'm
getting this error:
ERROR: datumGetSize: Invalid typLen 0
Many thanks to Teodor Sigaev for helping verify this bug. The following
test suite came from Teodor:
Reproduce bug:
initdb and start postmaster
%createdb foo
%psql foo bug.sql
CREATE TABLE
INSERT 16996 1
INSERT 16997 1
CREATE TABLE
INSERT 17003 1
ts_name | ts_name
-+-
default | default
default | default
(2 rows)
VACUUM
ERROR: datumGetSize: Invalid typLen 0
bug.sql is very simple:
CREATE TABLE pg_ts_cfgmap (
ts_name text
);
insert into pg_ts_cfgmap values ('default');
insert into pg_ts_cfgmap values ('default');
CREATE TABLE pg_ts_cfg (
ts_name text
);
insert into pg_ts_cfg values ('default');
select
*
from
pg_ts_cfgmap,
pg_ts_cfg
where
pg_ts_cfgmap.ts_name = pg_ts_cfg.ts_name;
vacuum analyze pg_ts_cfgmap;
select
*
from
pg_ts_cfgmap,
pg_ts_cfg
where
pg_ts_cfgmap.ts_name = pg_ts_cfg.ts_name;
---
Thomas
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] BUG: Vacuum Analyze - datumGetSize: Invalid typLen 0
Please also note that if you change the data type from text to int, then
the test succeeds:
CREATE TABLE wow_cfgmap (
ts_id int
);
insert into wow_cfgmap values (1);
insert into wow_cfgmap values (2);
CREATE TABLE wow_cfg (
ts_id int
);
insert into wow_cfg values (1);
select
*
from
wow_cfgmap,
wow_cfg
where
wow_cfgmap.ts_id = wow_cfg.ts_id;
vacuum analyze wow_cfgmap;
select
*
from
wow_cfgmap,
wow_cfg
where
wow_cfgmap.ts_id = wow_cfg.ts_id;
System: NetBSD / Alpha 1.6 (64 bit)
Postgresql 7.3.2
Bug: after vacuum analyze, I'm unable to do a simple select. Instead I'm
getting this error:
ERROR: datumGetSize: Invalid typLen 0
Many thanks to Teodor Sigaev for helping verify this bug. The following
test suite came from Teodor:
Reproduce bug:
initdb and start postmaster
%createdb foo
%psql foo bug.sql
CREATE TABLE
INSERT 16996 1
INSERT 16997 1
CREATE TABLE
INSERT 17003 1
ts_name | ts_name
-+-
default | default
default | default
(2 rows)
VACUUM
ERROR: datumGetSize: Invalid typLen 0
bug.sql is very simple:
CREATE TABLE pg_ts_cfgmap (
ts_name text
);
insert into pg_ts_cfgmap values ('default');
insert into pg_ts_cfgmap values ('default');
CREATE TABLE pg_ts_cfg (
ts_name text
);
insert into pg_ts_cfg values ('default');
select
*
from
pg_ts_cfgmap,
pg_ts_cfg
where
pg_ts_cfgmap.ts_name = pg_ts_cfg.ts_name;
vacuum analyze pg_ts_cfgmap;
select
*
from
pg_ts_cfgmap,
pg_ts_cfg
where
pg_ts_cfgmap.ts_name = pg_ts_cfg.ts_name;
---
Thomas
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] BUG: Vacuum Analyze - datumGetSize: Invalid typLen 0
On Wed, 2003-03-26 at 20:42, Thomas T. Thai wrote: [...] ERROR: datumGetSize: Invalid typLen 0 Works for me: [nconway:/home/nconway]% psql -f bug.sql CREATE TABLE INSERT 287424 1 INSERT 287425 1 CREATE TABLE INSERT 287431 1 ts_name | ts_name -+- default | default default | default (2 rows) VACUUM ts_name | ts_name -+- default | default default | default (2 rows) [...] Not to suggest that the bug doesn't exist -- merely that it appears to be platform or hardware-dependant. I think it's NetBSD / Alpha specific as it works on Linux / Alpha. There was a report of this problem on Linux Alpha back in 7.3.1: http://archives.postgresql.org/pgsql-bugs/2002-12/msg00215.php -- Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] string || NULL ambiguity
On Wed, 2003-03-19 at 20:32, Oleg Bartunov wrote:
On Wed, 19 Mar 2003, Alvaro Herrera wrote:
stringA||COALESCE(NULL, '')
we don't know in advance if it's NULL or not.
Right, that's the point of COALESCE: the first non-NULL argument is
returned -- so if the first argument to COALESCE happens to be non-NULL,
COALESCE has no effect.
I tried this with a txtidx column type:
tsearch=# select coalesce(NULL,'');
case
--
(1 row)
tsearch=# select coalesce(NULL,'hi');
case
--
hi
(1 row)
tsearch=# select title_fts from article;
title_fts
--
'2':3A 'tsearch':1A 'version':2A
'easi':1A 'implement':2A
(3 rows)
tsearch=# select coalesce('',title_fts) from article;
ERROR: Void value
tsearch=# select coalesce('hi',title_fts) from article;
case
--
'hi'
'hi'
'hi'
(3 rows)
---
Note the error: ERROR: Void value above. Why is that happening?
--
Thomas
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] string || NULL ambiguity
On Wed, 2003-03-19 at 20:32, Oleg Bartunov wrote:
On Wed, 19 Mar 2003, Alvaro Herrera wrote:
stringA||COALESCE(NULL, '')
we don't know in advance if it's NULL or not.
Right, that's the point of COALESCE: the first non-NULL argument is
returned -- so if the first argument to COALESCE happens to be
non-NULL, COALESCE has no effect.
I tried this with a txtidx column type:
tsearch=# select coalesce(NULL,'');
case
--
(1 row)
tsearch=# select coalesce(NULL,'hi');
case
--
hi
(1 row)
tsearch=# select title_fts from article;
title_fts
--
'2':3A 'tsearch':1A 'version':2A
'easi':1A 'implement':2A
(3 rows)
tsearch=# select coalesce('',title_fts) from article;
ERROR: Void value
tsearch=# select coalesce('hi',title_fts) from article;
case
--
'hi'
'hi'
'hi'
(3 rows)
---
Sorry the above should have been:
tsearch=# select coalesce(title_fts, '') from article;
ERROR: Void value
tsearch=# select coalesce(title_fts, 'hi') from article;
case
--
'2':3A 'tsearch':1A 'version':2A
'easi':1A 'implement':2A
'hi'
(3 rows)
Note the error: ERROR: Void value above. Why is that happening?
--
Thomas
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] What's up with www.postgresql.org?
On Fri, 7 Mar 2003, mlw wrote: I couldn't get to it yesterday either. FTP worked fine though. -- Thomas T. Thai ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
