[BUGS] BUG #8445: the database system is in recovery mode
The following bug has been logged on the website: Bug reference: 8445 Logged by: diaoqiwei Email address: dqwhappy...@163.com PostgreSQL version: 9.0.0 Operating system: centos Description: 2013-09-11 01:03:19 CST PANIC: stuck spinlock (0x2af93779bcd8) detected at dynahash.c:981 2013-09-11 01:03:19 CST STATEMENT: select user_id,user_password,user_nameen,user_namecn,user_officephone,user_mobile from oa_user where user_state=0 and user_nameen=$1 2013-09-11 01:03:22 CST PANIC: stuck spinlock (0x2af93779bcd8) detected at dynahash.c:981 2013-09-11 01:03:22 CST STATEMENT: select user_id,user_password,user_nameen,user_namecn,user_officephone,user_mobile from oa_user where user_state=0 and user_nameen=$1 2013-09-11 01:03:27 CST PANIC: stuck spinlock (0x2af93779bcd8) detected at dynahash.c:981 2013-09-11 01:03:27 CST STATEMENT: select user_id,user_password,user_nameen,user_namecn,user_officephone,user_mobile from oa_user where user_state=0 and user_nameen=$1 2013-09-11 01:03:30 CST LOG: server process (PID 14539) was terminated by signal 6: Aborted 2013-09-11 01:03:30 CST LOG: terminating any other active server processes 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8447: With table inheritance, indexes seems to be ignored when looking over indexed fields in base table
The following bug has been logged on the website: Bug reference: 8447 Logged by: David Carlos Manuelda Email address: stormb...@gmail.com PostgreSQL version: 9.3.0 Operating system: Gentoo Linux Description: In a simple table inheritance model, indexes seem to be ignored when looking at base table, this is a testcase: Table schema: CREATE TABLE base ( id SERIAL, email TEXT NOT NULL, PRIMARY KEY (id) ); CREATE TABLE derived1 ( otherData INTEGER, PRIMARY KEY (id) -- It is not inherited ) INHERITS (base); CREATE TABLE derived2 ( otherData2 BIGINT, PRIMARY KEY (id) -- It is not inherited ) INHERITS (base); Without any indexes the result is as expected: EXPLAIN SELECT id FROM base WHERE email='f...@foo.com'; QUERY PLAN --- Append (cost=0.00..48.25 rows=13 width=4) -> Seq Scan on base (cost=0.00..0.00 rows=1 width=4) Filter: (email = 'f...@foo.com'::text) -> Seq Scan on derived1 (cost=0.00..24.50 rows=6 width=4) Filter: (email = 'f...@foo.com'::text) -> Seq Scan on derived2 (cost=0.00..23.75 rows=6 width=4) Filter: (email = 'f...@foo.com'::text) Now I create triggers on each table (since it is a common field), to demonstrate how it is ignored: CREATE UNIQUE INDEX email_base_idx ON base(email); CREATE UNIQUE INDEX email_derived1_idx ON derived1(email); CREATE UNIQUE INDEX email_derived2_idx ON derived2(email); And now, see what the same select does: EXPLAIN SELECT id FROM base WHERE email='f...@foo.com'; QUERY PLAN - Append (cost=0.00..16.34 rows=3 width=4) -> Seq Scan on base (cost=0.00..0.00 rows=1 width=4) Filter: (email = 'f...@foo.com'::text) -> Index Scan using email_derived1_idx on derived1 (cost=0.15..8.17 rows=1 width=4) Index Cond: (email = 'f...@foo.com'::text) -> Index Scan using email_derived2_idx on derived2 (cost=0.15..8.17 rows=1 width=4) Index Cond: (email = 'f...@foo.com'::text) This is not the expected result. It can be seen that on base table, it is still using sequential scan rather than what would be expected: Index Scan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8448: looping through query results exits at 10th step under some conditions
The following bug has been logged on the website:
Bug reference: 8448
Logged by: László Rózsahegyi
Email address: laszlo.rozsahe...@rool.hu
PostgreSQL version: 9.3.0
Operating system: windows 7 64 bit
Description:
Looping through query results exits at 10th step when
* query has for update clause, and
* in loop body between 1 and 10 step update - at least one step - the locked
record
I tested it after a fresh and clean PostgreSQL install. The configuration
files left unchanged.
test code (bur_report.sql):
set client_encoding='UTF-8';
/* looping through query results exits at 10th step under some conditions
*/
create database looptest;
\c looptest
create sequence id_seq start 100;
create table test (
id bigint not null unique default nextval('id_seq')
, code varchar(3) not null
, note text
);
insert into test (code) values ('HUN'), ('ENG');
create type t_10 as (
num integer
, note text
);
select n.id, g.i
from test n
, generate_series(1,15) g(i)
where
n.code = 'HUN'
order by
2
;
/* The results are 15 rows */
create or replace function update10()
returns setof t_10
language plpgsql
volatile security definer
as
$BODY$
declare
lRec record;
lSor t_10;
begin
for lRec in
select n.id, g.i
from test n
, generate_series(1,15) g(i) /* 15 > 10 */
where
n.code = 'HUN'
order by
2
for update of n /* bug part 1 */
loop
lSor.num = lRec.i;
lSor.note = lRec.id::text || '-' || lRec.i::text;
/* exit loop after 10th step when update locked record in 1..10 step
otherwise returns all 15 record (example condition is lRec.i > 10 ) */
if lRec.i = 1 then
update test set note = lSor.note where id = lRec.id; /* bug part 2 */
end if;
return next lSor;
end loop;
return;
end;
$BODY$
;
select * from update10();
/* The results are 10 records */
\c postgres
drop database looptest;
-- end code
The last query results are 10 records. I expected 15 records, like the other
query.
I tested the code in windows 7 command prompt:
C:\temp>"c:\Program Files\PostgreSQL\9.3\bin\psql.exe" -Upostgres
-h127.0.0.1 -p5557 -f bug_report.sql
Password for user postgres:
SET
CREATE DATABASE
You are now connected to database "looptest" as user "postgres".
CREATE SEQUENCE
CREATE TABLE
INSERT 0 2
CREATE TYPE
id | i
-+
100 | 1
100 | 2
100 | 3
100 | 4
100 | 5
100 | 6
100 | 7
100 | 8
100 | 9
100 | 10
100 | 11
100 | 12
100 | 13
100 | 14
100 | 15
(15 rows)
CREATE FUNCTION
num | note
-+
1 | 100-1
2 | 100-2
3 | 100-3
4 | 100-4
5 | 100-5
6 | 100-6
7 | 100-7
8 | 100-8
9 | 100-9
10 | 100-10
(10 rows)
You are now connected to database "postgres" as user "postgres".
DROP DATABASE
C:\temp>
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8447: With table inheritance, indexes seems to be ignored when looking over indexed fields in base table
"stormb...@gmail.com" wrote: > [ Seq Scan is used on empty relation, rather than Index Scan ] > This is not the expected result. [ ... ] it is still using > sequential scan rather than what would be expected: Index Scan This is not a bug. If statistics indicate that all rows can be accessed with one page access (to the heap) why should it use an index? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #8444: ERROR: table name "tblb" specified more than once in subquery
A much more simple example courtesy of Chris Travers from the original -general thread that I suggested be moved to -bugs. > Here is a minimal query that demonstrates the problem. In 9.1 it works: > > chris=# select * FROM current_user u join (current_user u cross join > current_user v) x on true; >u | u | v > ---+---+--- > chris | chris | chris > (1 row) > > On 9.3 it fails: > ERROR: table name "u" specified more than once > > It may be a silly example but it works. -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-8444-ERROR-table-name-tblb-specified-more-than-once-in-subquery-tp5770540p5770654.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8449: ODBC Failure with Access 10
The following bug has been logged on the website: Bug reference: 8449 Logged by: Heike Pulsack Email address: pulsack.he...@gmx.de PostgreSQL version: 9.3.0 Operating system: Windows 8 Description: Hello, I'm not able to link in Access to the table "map". I get an ODBC error and in the table fields are no data, it returns "#Name?". Any idea what is wrong ? Regards Heike -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
