Franklin Schmidt | 11 Nov 07:58 2014
Picon

hello

http://thelendingmasters.com/thick.php?4j0ylwifhlcr41

fschmidt
fschmidt <at> gmail.com

+++++++
The life of every man is a diary in which he means to write one story,
and writes another. -- James Matthew Barrie

--

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

gavin.panella | 9 Nov 00:42 2014
Gravatar

BUG #11919: Serializable isolation issue: one session seeing writes from another session.

The following bug has been logged on the website:

Bug reference:      11919
Logged by:          Gavin Panella
Email address:      gavin.panella <at> canonical.com
PostgreSQL version: 9.3.5
Operating system:   Ubuntu 12.04
Description:        

I think I might have found a bug in PostgreSQL 9.3.5 relating to
serializable isolation, where code running within a savepoint can see
data committed in a second session after the commencement of the first,
but that data then "disappears" when the savepoint is rolled-back.

Of course, my understanding may be the bug, but here's how to reproduce
the effect:

1. Open two psql sessions to the same database.

2. Create an example table:

     create table things (a int unique);

3. In the first session:

     begin isolation level serializable;
     insert into things (a) values (1);

   Don't commit yet.

(Continue reading)

gopigarg729 | 10 Nov 07:31 2014
Picon

BUG #11926: warning

The following bug has been logged on the website:

Bug reference:      11926
Logged by:          gopi
Email address:      gopigarg729 <at> gmail.com
PostgreSQL version: 9.3.5
Operating system:   window 7
Description:        

console code page (437) differ from windows code page (1252)...............

--

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

nisam76 | 8 Nov 14:16 2014
Picon

BUG #11910: Database connection exhaustion

The following bug has been logged on the website:

Bug reference:      11910
Logged by:          nissam
Email address:      nisam76 <at> gmail.com
PostgreSQL version: 9.3.5
Operating system:   Windows 7
Description:        

Number of database connection reaching the limit 100 though my application
doesn't do any activity.

The log says continuous update as below and each of this looks like creating
a new connection and not closing the same.
I set the following property in the postgresql.conf already.
extra_float_digits = 3
Appreciate your help on this.

LOG:  execute <unnamed>: SET extra_float_digits = 3
LOG:  duration: 0.000 ms
LOG:  connection received: host=127.0.0.1 port=62175
LOG:  connection authorized: user=admin database=truesight
LOG:  duration: 0.000 ms
LOG:  duration: 0.000 ms
LOG:  execute <unnamed>: SET extra_float_digits = 3
LOG:  duration: 0.000 ms
LOG:  connection received: host=127.0.0.1 port=62192
LOG:  connection authorized: user=admin database=truesight
LOG:  duration: 0.000 ms
LOG:  duration: 0.000 ms
(Continue reading)

connor.penhale | 7 Nov 22:56 2014

BUG #11905: "Error: Wrong key or corrupt data" with pgp_sym_decrypt when bytea size is 2^x - 6 where x >=14

The following bug has been logged on the website:

Bug reference:      11905
Logged by:          Connor Penhale
Email address:      connor.penhale <at> openlogic.com
PostgreSQL version: 9.3.1
Operating system:   OS X Yosemitie
Description:        

Hello Postgres Community,

When I attempt to decrypt a file I successfully encrypted with a size of
65530, I get the “Error: Wrong key or corrupt data” message.

Here are the steps to reproduce in plain text:

$ head -c 65536 </dev/urandom > can_decode.txt
$ head -c 65530 </dev/urandom > can_not_decode.txt
$ psql 

create or replace function bytea_import(p_path text, p_result out bytea)
language plpgsql as $$
declare
l_oid oid;
r record;
begin
p_result := '';
select lo_import(p_path) into l_oid;
for r in ( select data
from pg_largeobject
(Continue reading)

Rémi Zara | 7 Nov 23:25 2014
Picon

Build broken on mips

Hi,

The build is broken on mips on the HEAD branch.
Here is a patch to fix that (builds and make check is OK on NetBSD/cobalt 7.99.1, GCC 4.8.4):

--- ../pgsql/src/include/storage/s_lock.h       2014-11-05 21:01:05.000000000 +0100
+++ src/include/storage/s_lock.h        2014-11-06 23:12:42.000000000 +0100
 <at>  <at>  -601,9 +601,10  <at>  <at> 
                "       .set noreorder      \n" \
                "       .set nomacro        \n" \
                "       sync                \n" \
-               "       .set pop              "
-:
-:              "memory");
+               "       .set pop              " \
+: \
+: \
+:              "memory"); \
        *((volatile slock_t *) (lock)) = 0; \
 } while (0)

Regards,

Rémi Zara

--

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

(Continue reading)

koposov | 7 Nov 19:58 2014
Picon
Picon

BUG #11904: out of memory when scanning large number of partitions

The following bug has been logged on the website:

Bug reference:      11904
Logged by:          Sergey Koposov
Email address:      koposov <at> ast.cam.ac.uk
PostgreSQL version: 9.3.5
Operating system:   RHEL 6.6
Description:        

Hi, 

I have a large table (few Tb) partitioned in ~ 12000 smaller tables, using
inheritance from the parent one. 
I noticed that when the user tried to query from the parent table 
(not something we plan to do often), PG run out of memory (128 Gb on our
machine). It is particularly surprising that even after I repeated the
query simplifying it to

select 1  from photometry_parent where flux1>1e20;

and ensuring that NO rows satisfy the condition. 
PG still ran out of memory. 
Surely this looks like a bug ? 

Below I put  the memory context dump that PG put in the log. 
I also put the schema of the table below.

Something that could be relevant -- I'm doing this on the hot standby
 machine ( I didn't try this on our master ).

(Continue reading)

dimon99901 | 7 Nov 07:21 2014
Picon

BUG #11903: Segmentation fault

The following bug has been logged on the website:

Bug reference:      11903
Logged by:          Dmitry
Email address:      dimon99901 <at> mail.ru
PostgreSQL version: 9.3.4
Operating system:   Debian 7.7 (Wheezy)
Description:        

I saw in postgres log following messages:

2014-11-06 13:58:02 GMT LOG:  server process (PID 44060) was terminated by
signal 11: Segmentation fault
2014-11-06 13:58:02 GMT DETAIL:  Failed process was running: select id_user
from site.items where id_item = '10795593'
2014-11-06 13:58:02 GMT LOG:  terminating any other active server processes
2014-11-06 13:58:02 GMT WARNING:  terminating connection because of crash of
another server process
2014-11-06 13:58:02 GMT 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.

Further, postgres generates 6Kiops for 2min on the HDD (I assume that
postgres checked data for corruption).

This situation occures 1 times a day for 2 days.

I planned upgrade to 9.3.5, but i have not seen this bug in 9.3.5 release
notes.

(Continue reading)

louellet | 6 Nov 17:48 2014
Picon

BUG #11901: Full text search: thesaurus size limit

The following bug has been logged on the website:

Bug reference:      11901
Logged by:          Luc Ouellette
Email address:      louellet <at> nrcan.gc.ca
PostgreSQL version: 9.3.4
Operating system:   &quot;PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu
Description:        

I work for a national mapping agency and I am trying to build a thesaurus
dictionary loan 300000 lines.
When I go over 65535 lines the query aborts. This problem was already
reporter (see BUG # 7793: tsearch_data thesaurus size limit) and was
corrected with PG 9.2.2. This correction was not spread in the most recent
versions of postgresql.

My pgAdmin can compile a version corrected by updating the tsearch src /
backend / / dict_thesaurus.c
and use uint32 instead of uint16 entry's number in DictThesaurus.
This solution would oblige us to maintain a branch unofficial PostgreSQL and
this is not desirable.

Is it possible that this correction is to formalize and apply it permanently
on the next version of PostgreSQL?

Regards,
Luc Ouellette

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
(Continue reading)

Burgess, Freddie | 7 Nov 00:37 2014

Invalid page in block on autovacuum

Logged by:          Freddie Burgess
Email address:     fburgess <at> radiantblue.com
PostgreSQL version: 9.3.4
Operating system:   Red_hat Linux 6.4
Description:

Our production log recorded these Errors today

20296____ERROR: Invalid page in block 1225978 of relation pg_tblspc/16434/PG_9.3_201306121/16444/125126685
20296____CONTEXT: automatic vacuum of table sensordb.public.doti_domain_y2006m12  <-- partition table
doti_domain

...
11051____ERROR: Invalid page in block 610813 of relation pg_tblspc/16442/PG_9.3_201306121/16444/125127325  <-- file 125127325 doesn't exist
11051____CONTEXT: automatic vacuum of table sensordb.pg_toast.pg_toast_125118423

...
11051____ERROR: Invalid page in block 447869 of relation pg_tblspc/16440/PG_9.3_201306121/16444/125128155
11051____CONTEXT: automatic vacuum of table sensordb.
public.doti_source_node_y2012m10        <-- partition table doti_source_node

Is this cause for alarm?

I  can still select rows from these tables.

Thanks


lr | 6 Nov 19:01 2014
Picon

BUG #11902: PostgreSQL 9.5 crashes on alter table in function

The following bug has been logged on the website:

Bug reference:      11902
Logged by:          Regina Obe
Email address:      lr <at> pcorp.us
PostgreSQL version: Unsupported/Unknown
Operating system:   Debian and Windows MingW-w64 (both 64 and 32-bit)
Description:        

I wanted to pick 9.5 in PostgreSQL version, but that is not listed.  Anyway
for the past couple of weeks regressing against latest snapshots of 9.5 has
been crashing our PostGIS topology tests.

Related ticket here:
http://trac.osgeo.org/postgis/ticket/2982

I was able to crash without PostGIS help with this script:

CREATE OR REPLACE FUNCTION crash_test(table_name varchar, column_name
varchar)
  RETURNS bigint AS
$$
DECLARE
 var_result bigint;
BEGIN
       EXECUTE 'ALTER TABLE ' || quote_ident(table_name) || ' ADD COLUMN '
|| quote_ident(column_name) || ' text;';
       var_result = (random()*100000)::bigint;
       RETURN var_result;
END
$$
  LANGUAGE plpgsql VOLATILE
  COST 100;

DROP TABLE IF EXISTS test_1;
CREATE TABLE test_1(id serial primary key);
DROP TABLE IF EXISTS test_crash;
CREATE TEMP TABLE test_crash AS 
SELECT 1 As id, crash_test('test_1', 'lyr1') As layer;

INSERT INTO test_crash(id, layer)
SELECT id + 1, crash_test('test_1', 'lyr' || (id + 1)::text)
FROM test_crash
WHERE id = 1;

Our buildbot runs Debian 64-bit, and I also tested this on my Mingw64
Windows 7 both (64-bit and 32-bit with same issue)

Issue seems to be around here according to gdb trace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5568.0x15c4]
0x000000000054fbc9 in AfterTriggerPendingOnRel (relid=17984) at
trigger.c:4781
4781                    for_each_event_chunk(event, chunk,
afterTriggers.query_stack[depth])
(gdb) bt
#0  0x000000000054fbc9 in AfterTriggerPendingOnRel (relid=17984) at
trigger.c:4781
#1  0x000000000053e05c in CheckTableNotInUse (rel=0xe650dc0, stmt=0x8ab69a
<__func__.77621+8091> "ALTER TABLE") at tablecmds.c:2652
#2  0x0000000000545315 in AlterTable (relid=relid <at> entry=17984,
lockmode=lockmode <at> entry=8, stmt=0xe32b580) at tablecmds.c:2724

--

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