clime7 | 28 Mar 00:07 2014
Picon

BUG #9749: ERROR: unexpected classid 3600

The following bug has been logged on the website:

Bug reference:      9749
Logged by:          clime
Email address:      clime7 <at> gmail.com
PostgreSQL version: 9.2.4
Operating system:   linux
Description:        

I am getting this error when trying to execute "reassign owned" command.

cb_test=# reassign owned by clime to cb_test;
ERROR:  unexpected classid 3600
cb_test=# select '3600'::regclass;
  regclass  
------------
 pg_ts_dict
(1 row)

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

digoal | 28 Mar 04:51 2014

BUG #9751: PostgreSQL free btree index page cann't reuse bug?

The following bug has been logged on the website:

Bug reference:      9751
Logged by:          digoal.zhou
Email address:      digoal <at> 126.com
PostgreSQL version: 9.3.3
Operating system:   CentOS 6.4 x64
Description:        

PostgreSQL free btree index page cann't reuse in the future?
This is my test : 
digoal=# create table test(id int primary key, info text, crt_time
timestamp);
CREATE TABLE
digoal=# insert into test select
generate_series(1,50000000),md5(random()::text),clock_timestamp();
INSERT 0 50000000
digoal=# \dt+ test
                    List of relations
 Schema | Name | Type  |  Owner   |  Size   | Description 
--------+------+-------+----------+---------+-------------
 public | test | table | postgres | 3634 MB | 
(1 row)
digoal=# \di+
                           List of relations
 Schema |   Name    | Type  |  Owner   | Table |  Size   | Description 
--------+-----------+-------+----------+-------+---------+-------------
 public | test_pkey | index | postgres | test  | 1063 MB | 
(1 row)
digoal=# copy (select * from test where id<>50000000) to
(Continue reading)

sdl | 28 Mar 08:58 2014
Picon

BUG #9756: Inconsistent database after OS restart

The following bug has been logged on the website:

Bug reference:      9756
Logged by:          Dmitry Samokhin
Email address:      sdl <at> mnppsaturn.ru
PostgreSQL version: 9.2.8
Operating system:   Windows XP, 7
Description:        

After every Windows restart, database couldn't be shut down properly and
recovering actions are performed on the next startup. But if we control the
service manually by the Windows Services snap-in, no problem with the
correct DB cluster shutdown. Looks like there's something wrong with the
correct autovacuum process shutdown which leads to the DB inconsistency.

Custom configuration options:
autovacuum_naptime = '1d'
The others are default.

Here is the log entries:

*** Manual service start ***

2014-03-28 11:36:05 MSK LOG:  database system was shut down at 2014-03-28
11:35:39 MSK
2014-03-28 11:36:05 MSK LOG:  database system is ready to accept
connections
2014-03-28 11:36:05 MSK LOG:  autovacuum launcher started

*** Manual service stop ***
(Continue reading)

kwalbrecht | 27 Mar 14:21 2014

BUG #9743: subquery on view is not pulling up.

The following bug has been logged on the website:

Bug reference:      9743
Logged by:          Karl Walbrecht
Email address:      kwalbrecht <at> cghtech.com
PostgreSQL version: 9.2.1
Operating system:   solaris
Description:        

When I query a view which has calculated values, even if I don't select one
of the calculated values, they are being calculated.  I believe this is
called subquery unnesting in oracle.  In essence since the calculated
portion of the table is not being referenced then the calculation should not
be preformed.  I tried setting the cost of sda.KML_Sector() and
sda.GeoJSON_Sector() to 150000 but it had no effect on the query plan.  I
have tried rewriting the queries but again to no effect.  I have concluded
that this is a performance issue in the query optimization routines.  I
apologize in advance if this is just stupidity on my part.

Thanks

The functions sda.KML_sector(), and sda.GeoJSON_Sector() are written in
pgplsql.

CREATE TABLE sda.sectors_base_table
( 
    sector_id         INTEGER   NOT NULL
  , airspace_id       INTEGER   NOT NULL
  , area_id           INTEGER   NOT NULL
  , sector_num        VARCHAR   NOT NULL
(Continue reading)

maxim.boguk | 27 Mar 10:33 2014
Picon

BUG #9741: Mininal case for the BUG #9735: Error: "ERROR: tuple offset out of range: 0" during bitmap scan

The following bug has been logged on the website:

Bug reference:      9741
Logged by:          Maxim Boguk
Email address:      maxim.boguk <at> gmail.com
PostgreSQL version: 9.3.3
Operating system:   Linux (Ubuntu)
Description:        

Hi,

How situation with the BUG #9735 become even more curious.

One query successfully executing on master db but doesn't work on both
streaming replicas.
After much digging I located problem and produced it in pretty simple way:

gate_platbox=# set enable_indexscan to 0;
SET
(force bitmap scan)
gate_platbox=# explain analyze select * from transactions where
id=53265020;
ERROR:  tuple offset out of range: 0

This tuple had been frozen not that long time ago:

gate_platbox=# select id,xmin,xmax,cmin,cmax,ctid from transactions where
id=53265020;
    id    | xmin | xmax | cmin | cmax |    ctid
----------+------+------+------+------+-------------
(Continue reading)

kochismo | 26 Mar 18:32 2014
Picon

BUG #9737: Trigram Regex degenerate case

The following bug has been logged on the website:

Bug reference:      9737
Logged by:          Ka Chun Leung
Email address:      kochismo <at> gmail.com
PostgreSQL version: 9.3.4
Operating system:   Ubuntu Lucid
Description:        

Trigram regexes don't seem to handle ranges well.

Without ranges my query runs fine:

explain analyse select * from foos where foo::text ~ 'abc.+def'

Bitmap Heap Scan on foos  (cost=23032.42..25164.29 rows=571 width=56)
(actual time=57.996..62.183 rows=43 loops=1)
  Recheck Cond: ((foo)::text ~ 'abc.+def'::text)
  Rows Removed by Index Recheck: 953
  ->  Bitmap Index Scan on idx_foos_foo_trgm_gin  (cost=0.00..23032.28
rows=571 width=0) (actual time=57.741..57.741 rows=996 loops=1)
        Index Cond: ((foo)::text ~ 'abc.+def'::text)
Total runtime: 62.211 ms

With ranges:

explain analyse select * from foos where foo::text ~ 'abc[0-9]+def'

Bitmap Heap Scan on foos  (cost=27588.42..29720.29 rows=571 width=56)
(actual time=7844.767..7844.993 rows=3 loops=1)
(Continue reading)

correio.vip | 26 Mar 14:18 2014
Picon

BUG #9736: incomplete odbc

The following bug has been logged on the website:

Bug reference:      9736
Logged by:          Paulo Marques
Email address:      correio.vip <at> gmail.com
PostgreSQL version: 9.3.4
Operating system:   Windows 64 bits
Description:        

from version 9.3 ..... this in error, installs but does not work for lack of
components: 
32-bit version when installed on Windows 64-bit. 

noticed that the Installer can Tamano msi version of 9:02 to 9:03 was half
the size.

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Dang Minh Huong | 26 Mar 16:08 2014
Picon

Duplicated row after promote in synchronous streaming replication

Hi all,

I'm using PostgreSQL 9.1.10 for my HA project and have found this problem.

I did (multiple times) the following sequence in my primary/standby synchronous replication environment,

1. Update rows in a table (which have primary key constraint column) in active DB

2. Stop active DB

3. Promote standby DB

4. Confirm the updated table in promoted standby (new primary) and found that, there's a duplicate updated row (number of row was increased).

I think it is a replication bug but wonder if it was fixed yet. 
Can somebody help me?

I'm not yet confirm PostgreSQL source, but here is my investigation result.

Updated table before promoted were HOT update (index file was not changed).

After promote i continue update that duplicated row (it returned two row updated), and confirm with pg_filedump, i found the duplicated row and only one is related to primary key index constraint.

Compare with old active DB, i saw that after promote line pointer of updated row (duplicated row) is broken into two line pointer, the new one is related to primary index constraint and the other is not related to. Some thing like below, 

Old active DB:
ctid(0,3)->ctid(0,6)->ctid(0,7)

New active DB (after promote and update):
ctid(0,3)->ctid(0,9)
ctid(0,7)->ctid(0,10)

ctid(0,10) is not related to primary key index constraint.

Is something was wrong in redo log in standby DB? Or line pointer in HOT update feature?

Thanks and best regards,
Huong,
maxim.boguk | 26 Mar 13:11 2014
Picon

BUG #9735: Error: "ERROR: tuple offset out of range: 0" during bitmap scan

The following bug has been logged on the website:

Bug reference:      9735
Logged by:          Maxim Boguk
Email address:      maxim.boguk <at> gmail.com
PostgreSQL version: 9.3.3
Operating system:   Linux
Description:        

Hi,

An application start getting curious error during simple query:

select * from transactions where  (date(provider_tx_datetime) =
'2014-03-13'::date);
ERROR:  tuple offset out of range: 0

Plan:
 Bitmap Heap Scan on transactions  (cost=614.04..32037.39 rows=167485
width=608)
   Recheck Cond: (date(provider_tx_datetime) = '2014-03-13'::date)
   ->  Bitmap Index Scan on transactions_tx_prv_tx_dt_date_idx21 
(cost=0.00..572.17 rows=167485 width=0)
         Index Cond: (date(provider_tx_datetime) = '2014-03-13'::date)

What doesn't helped:
set vacuum_freeze_table_age to 0;
vacuum freeze verbose transactions;
and rebuilding the transactions_tx_prv_tx_dt_date_idx21 index.

What helped:
set enable_bitmapscan to 0;
and executing the same query again
with plan:
 Index Scan using transactions_tx_prv_tx_dt_date_idx21 on transactions 
(cost=0.56..33915.12 rows=167485 width=608) (actual time=0.047..1233.998
rows=195824 loops=1)
   Index Cond: (date(provider_tx_datetime) = '2014-03-13'::date)
 Total runtime: 1247.688 ms
afterward.

This situation repeated more few times over the last days (with diferen
dateranges).

Any suggestions where and what for I should look next?

It seems somehow related with visibility map and bitmap scan interaction
(only my theory though).

Kind Regards,
Maksym

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Rainer Tammer | 25 Mar 17:39 2014

Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1

Hello,
Here is a little status update:

If you compile PostgreSQL 9.2.7 on AIX 7.1 TL2 and then copy the
binaries to a AIX 7.1 TL3 everything is fine - no hangs.

It does look like the C/C++ compiler (same version/patch level) is
producing a working binary on AIX 7.1 < TL3 and failing one on AIX 7.1 =
TL3 (latest OS level available).

Currently the IBM kernel development support is analyzing the problem.

Bye
  Rainer

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

postgresql | 25 Mar 12:59 2014
Picon

BUG #9721: Fatal error on startup: no free slots in PMChildFlags array

The following bug has been logged on the website:

Bug reference:      9721
Logged by:          Daniel Hahler
Email address:      postgresql <at> thequod.de
PostgreSQL version: 9.3.3
Operating system:   Debian
Description:        

PostgreSQL just failed to startup after a reboot (which was forced via
remote Ctrl-Alt-Delete on the PostgreSQL's containers host):

2014-03-24 13:32:47 CET LOG:  could not receive data from client: Connection
reset by peer
	2014-03-25 12:32:17 CET FATAL:  no free slots in PMChildFlags array
2014-03-25 12:32:17 CET LOG:  process 9975 releasing ProcSignal slot 108,
but it contains 0
2014-03-25 12:32:17 CET LOG:  process 9974 releasing ProcSignal slot 109,
but it contains 0
2014-03-25 12:32:17 CET LOG:  process 9976 releasing ProcSignal slot 110,
but it contains 0

I have found that the source code says that this should never happen:

    /* Out of slots ... should never happen, else postmaster.c messed up */
    elog(FATAL, "no free slots in PMChildFlags array");

Another attempt at starting it worked:

2014-03-25 12:38:43 CET LOG:  database system was interrupted; last known up
at 2014-03-24 18:22:38 CET
2014-03-25 12:38:43 CET LOG:  database system was not properly shut down;
automatic recovery in progress
2014-03-25 12:38:43 CET LOG:  incomplete startup packet
2014-03-25 12:38:44 CET LOG:  record with zero length at 0/7843020
2014-03-25 12:38:44 CET LOG:  redo is not required
2014-03-25 12:38:44 CET LOG:  autovacuum launcher started
2014-03-25 12:38:44 CET LOG:  database system is ready to accept
connections

I am using 9.3.3-1.pgdg70+1 from http://apt.postgresql.org/pub/repos/apt/ on
a Debian Wheezy system, running in an OpenVZ container.

I have just now noticed that 9.3.4 has been released, and upgraded to it. I
am sorry if that's something that has been fixed in that update already. 

Thanks!

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Gmane