haribabu.kommi | 18 Apr 13:18 2013

BUG #8091: No permissions on the table file causing recovery failure

The following bug has been logged on the website:

Bug reference:      8091
Logged by:          Hari Babu
Email address:      haribabu.kommi <at> huawei.com
PostgreSQL version: 9.2.4
Operating system:   Linux
Description:        

During the testing of fixed old defect with some altered scenario leads to a
defect. 

Fixed old defect description in release 9.1.3:

Avoid crashing when we have problems deleting table files post-commit (Tom
Lane)
Dropping a table should lead to deleting the underlying disk files only
after the transaction commits. In event of failure then (for instance,
because of wrong file permissions)
the code is supposed to just emit a warning message and go on, since it's
too late to abort the transaction. This logic got broken as of release 8.4,

causing such situations to result in a PANIC and an unrestartable database.

New defect scenario:
1. create table.
2. change the file permissions.
3. Drop table.
4. Restart the server leads to recovery failure.

(Continue reading)

victor | 17 Apr 19:59 2013

BUG #8080: 32-bit ODBC Driver Needs timestamp MetaData Type

The following bug has been logged on the website:

Bug reference:      8080
Logged by:          Victor Reinhart
Email address:      victor <at> maintstar.com
PostgreSQL version: 9.2.4
Operating system:   Windows XP
Description:        

When using PowerBuilder to connect to Postgres using the latest 32-bit ODBC
Driver, there is no "timestamp" MetaData Type.  The closest type is
"timestamptz" which PowerBuilder doesn't understand, and can't be configured
to use.  The Progress Data Direct ODBC Driver has both "timestamp" and
"timestamp with timezone" types.  The "timestamp" type is usable in
PowerBuilder.  However, it must be purchased for each user.  It would be
very helpful if the ODBC Driver had the "timestamp" MetaData Type.

--

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

krzbia | 17 Apr 11:27 2013
Picon

BUG #8079: pg_ctl is killed by windows service controller due to "Timed out waiting for server startup" event

The following bug has been logged on the website:

Bug reference:      8079
Logged by:          Christopher Bialas
Email address:      krzbia <at> interia.pl
PostgreSQL version: 9.2.4
Operating system:   Microsoft Windows 2008R2 Standard server
Description:        

With very high load of the server during startup (e.g.  simultaneous logon
to local console) pg_ctl is being killed by windows service controller as it
does not respond on time. I've seen it with process explorer:
1. pg_ctl starts, then
2. postgres processing tasks start
3. pg_ctl is killed leaving postgres workers running.

As a result windows service is totally confused as service is dead, and it
cannot be started again as it finds out that postgres is already running.

The following is the excerpt from windows log:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="PostgreSQL" /> 
  <EventID Qualifiers="0">0</EventID> 
  <Level>4</Level> 
  <Task>0</Task> 
  <Keywords>0x80000000000000</Keywords> 
  <TimeCreated SystemTime="2013-04-17T09:04:31.000000000Z" /> 
  <EventRecordID>227797</EventRecordID> 
  <Channel>Application</Channel> 
(Continue reading)

Sofer, Yuval | 17 Apr 11:09 2013
Picon

general question and BUG #5038

Hi

 

how do I review list of bugs reported as  fixed for each Postgres version?

 

Is there any quick way to detect a fix of bug using Bug id?

 

I saw the “changes” section in each major release documentation (appendixes ->release notes->changes), but should I read it all rather than search using some BUG ID ?

 

And specifically for  bug #5038 – was it fix in version 8.3.8 or in higher Postgres version?

 

Thanks

 

Yuval Sofer

BMC Software

CTM&D Business Unit

DBA Team

972-52-4286-282

yuval_sofer <at> bmc.com

 

 

 

 

kako | 14 Apr 08:59 2013
Picon

BUG #8067: now() bug?

The following bug has been logged on the website:

Bug reference:      8067
Logged by:          Istvan Kassai
Email address:      kako <at> zhnet.hu
PostgreSQL version: 9.0.1
Operating system:   Linux DRONE 2.6.32.27 #5 Wed Dec 21 12:11:46 CET 2
Description:        

function "now()" sometimes returns with a value with timezone data,
sometimes without.

for example:

*****************************************
therm=# select now();
            now
----------------------------
 2013-04-14 06:58:12.056065
(1 row)

therm=# select now();
              now
-------------------------------
 2013-04-14 08:58:12.766165+02
(1 row)

therm=# select now();
            now
----------------------------
 2013-04-14 06:58:16.046629
(1 row)
*****************************************

is it a bug or a feature?

--

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

fburgess | 12 Apr 20:31 2013

Partition performance causing ddl commands to slow down significantly

We are having performance related problems on one of our big data Partition tables. The table is partitioned by date and the partitions are organized from Jan 2003 thru Dec 2013.
We have 268 child partitions associated with the Parent table, and we have constraint_exclusion=partition set.
 
The execution of the SQL query:  select count(*) from dna_strands;
yields:                                                           QUERY PLAN
_____________________________________________________________________________________________  
Aggregate (cost=2246778.49..2246778.50 rows=1 width=0)
  -> Append (0.00..2159647.04 rows=34852580 width=0)
     -> Seq Scan on dna_strands (cost=0.00..0.00 rows=1 width)
          Filter: (cid = 1)
     -> Index Scan using dna_strands_y2003m01_cid on dna_strands_y2003m01 dna_strands (cost=0.00..677652 rows=1 width=0)
           Index Cond: (cid = 1)
     -> Index Scan using dna_strands_y2003m02_cid on dna_strands_y2003m02 dna_strands (cost=0.00..974423 rows=1 width=0)
           Index Cond: (cid = 1)
     -> Index Scan using dna_strands_y2003m03_cid on dna_strands_y2003m03 dna_strands (cost=0.00..992301 rows=1 width=0)
           Index Cond: (cid = 1)
     ...
     ...
     ...
 
     -> Index Scan using dna_strands_y2013m12_cid on dna_strands_y2013m12 dna_strands (cost=0.00..8.27 rows=1 width=0)
           Index Cond: (cid = 1)
Question: Is there any way to modify the Planner to do the inverse of the Index Scan's.  In other words, to start the index scans in reverse order from
the most recent date to the oldest date, i.e. "dna_strands_y2013m12" backwards. Our application users query much more heavily at the most recent data that
has been ingested into the PostgreSQL database.  Would this capability speed up query performance?
Thanks

 
claudiomsi | 12 Apr 16:57 2013
Picon

BUG #8061: Not count limit offset

The following bug has been logged on the website:

Bug reference:      8061
Logged by:          Claudio Oliveira
Email address:      claudiomsi <at> hotmail.com
PostgreSQL version: 9.2.4
Operating system:   WIN 8
Description:        

select count(*) from teste; --- 5000
select count(*) from teste limit 1000 offset 0; --- 5000
select count(*) from teste limit 1000 offset 1; --- not returning 

--

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

rajuk058 | 12 Apr 06:39 2013
Picon

BUG #8057: Unable to Connect PostgresSQL Remotely

The following bug has been logged on the website:

Bug reference:      8057
Logged by:          Raju
Email address:      rajuk058 <at> gmail.com
PostgreSQL version: 9.2.0
Operating system:   windows 7
Description:        

Dear Sir,

I am unable to connect postgresSQL from local machine to database on
server.I request to please help me out to resolve this problem as soon as
possible.

Thanks & Regard
Raju

--

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

Singh, Devendra | 12 Apr 08:41 2013
Picon

postgres 8.4 PQexec hang on HP-UX

Hi All,

 

I hit a hang issue in postgres 8.4 query. Hit this issue multiple time on HP-UX. Below is the snapshot of the hang thread.

 

--------------------------------  lwpid : 600943   -------------------------------

0: c00000000054ced0 : _poll_sys() + 0x30 (/usr/lib/hpux64/libc.so.1)

1: c000000000561560 : poll() + 0xe0 (/usr/lib/hpux64/libc.so.1)

2: c000000001f798e0 : pqSocketPoll() at fe-misc.c:1079

3: c000000001f790e0 : pqWait() at fe-misc.c:1024

4: c000000001f6ebb0 : PQgetResult() at fe-exec.c:1554

5: c000000001f6f0a0 : PQexec() at fe-exec.c:1735

 

Is it a known issue? Any possible workaround ?

 

Thanks & Regards,

Devendra Singh

 

 

shaun.c.mccrery | 12 Apr 15:04 2013
Picon

BUG #8060: postgresql service not in Microsoft services

The following bug has been logged on the website:

Bug reference:      8060
Logged by:          Shaun McCrery
Email address:      shaun.c.mccrery <at> saic.com
PostgreSQL version: 9.2.4
Operating system:   Server 2008 R2 x64
Description:        

I upgraded to 9.2.4 and now the postgresql service is not available in
Microsoft services. The availability to start and stop the service is not
there. It was there before I performed the upgrade

--

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

tarvip | 12 Apr 14:27 2013
Picon

BUG #8059: sequence crash recovery is not working properly

The following bug has been logged on the website:

Bug reference:      8059
Logged by:          Tarvi Pillessaar
Email address:      tarvip <at> gmail.com
PostgreSQL version: 9.2.4
Operating system:   linux
Description:        

Very simple example:

postgres <at> sbox /usr/local/pgsql $ /usr/local/pgsql/bin/psql test
psql (9.2.4)
Type "help" for help.

test=# create sequence s;
CREATE SEQUENCE
test=# begin;
BEGIN
test=# select nextval('s');
 nextval 
---------
       1
(1 row)

Now let's crash the cluster:

postgres <at> sbox /usr/local/pgsql $ pgrep -lf writer
13638 postgres: writer process
13639 postgres: wal writer process
postgres <at> sbox /usr/local/pgsql $ kill -9 13638
postgres <at> sbox /usr/local/pgsql $ tail logfile 
HINT:  In a moment you should be able to reconnect to the database and
repeat your command.
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted; last known up at 2013-04-12 14:28:26
EEST
LOG:  database system was not properly shut down; automatic recovery in
progress
LOG:  redo starts at 0/177C9E0
LOG:  record with zero length at 0/1791888
LOG:  redo done at 0/1791858
LOG:  last completed transaction was at log time 2013-04-12
14:29:48.562356+03
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
postgres <at> sbox /usr/local/pgsql $ 

test=# select nextval('s');
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and
repeat your command.
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: Succeeded.
test=# select nextval('s');
 nextval 
---------
       1
(1 row)

test=# 

This problem occurs on the same conditions as described in commit
af026b5d9b8ae6ef4c75a796bdac209df6411181.

For another example i'm going to use very simple python script:
import psycopg2
cur = psycopg2.connect('dbname=test host=/tmp/').cursor()
while True:
    try:
        cur.execute("select nextval('s')")
        val=cur.fetchone()[0]
    except Exception, e:
        print "%s\n%s" % (val,e)
        break

This script consumes a lot of values from sequence 's' within a single
transaction, when crash occurs it prints out last value that the script got
from database.

postgres <at> sbox /usr/local/pgsql $ python test.py 
132119
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

postgres <at> sbox /usr/local/pgsql $ /usr/local/pgsql/bin/psql test
psql (9.2.4)
Type "help" for help.

test=# select nextval('s');
 nextval 
---------
  130501
(1 row)

test=#

--

-- 
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