erich | 23 Feb 11:26 2015

BUG #12797: Cannot compile pgAgent

The following bug has been logged on the website:

Bug reference:      12797
Logged by:          Erich
Email address:      erich <at> npp-asia.com
PostgreSQL version: 9.4.1
Operating system:   Windows 7 SP1
Description:        

I was downloading pgAgent Source Code and its stuck on 

Error	5	error LNK1104: cannot open file
'wxbase28ud.lib'	D:\C++_PROJECT\build_dir\LINK	pgagent

Can I have the pgAgent.exe please or give me more step by step for compiling
it with Visual Studio 2012

--

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

lr | 20 Feb 16:08 2015
Picon

BUG #12792: I can do a SELECT with no fields

The following bug has been logged on the website:

Bug reference:      12792
Logged by:          Regina Obe
Email address:      lr <at> pcorp.us
PostgreSQL version: 9.4.1
Operating system:   Windows 2008 R2
Description:        

I'm not sure if this is a bug or not, but it seems like a misfeature if it
isn't.

I made the typo of doing

SELECT FROM sometable;

you can also trigger the issue with just doing:

SELECT ;

outputs:
--
(1 row)

I thought there was something wrong with my viewer since it clearly showed
rows, but no fields.

In 9.3 -- this would just error out as I think most databases do.  So this
was a bit of a gotcha.

(Continue reading)

programble | 20 Feb 05:30 2015
Picon

BUG #12789: Views defined with VALUES lose their column names when dumped

The following bug has been logged on the website:

Bug reference:      12789
Logged by:          Curtis McEnroe
Email address:      programble <at> gmail.com
PostgreSQL version: 9.4.1
Operating system:   Mac OS X 10.10.1
Description:        

A view created with explicit column names and defined as a VALUES statement
will lose its column names when dumped. When the dump is restored, the
view's columns are named "column1", "column2", etc.

I wrote a short repro script here:
https://gist.github.com/programble/a416df496bfb41259c86

--

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

dannyman | 19 Feb 18:44 2015
Gravatar

BUG #12788: host / peer auth works after pg_ctl reload, then blocks server startup

The following bug has been logged on the website:

Bug reference:      12788
Logged by:          Daniel Howard
Email address:      dannyman <at> toldme.com
PostgreSQL version: 9.3.2
Operating system:   CentOS
Description:        

Hello,

I naively added a line like this to pg_hba.conf:

host   all             postgres        x.x.x.x/32           peer

I ran pg_ctl reload.

I was then able to connect from x.x.x.x to do backups.

I then restarted the server, and it failed, with this error:

LOG:  peer authentication is only supported on local sockets

I removed the above line from pg_hba.conf and server completed startup.  I
can no longer connect from host x.x.x.x.

I can see why pg_ctl reload might gloss over a config issue instead of
bringing down the server, but that the invalid auth configuration then works
strokes me as a bug.

(Continue reading)

daniele.posenato | 19 Feb 10:55 2015
Picon

BUG #12785: server process (PID 2872) was terminated by exception 0xC0000005

The following bug has been logged on the website:

Bug reference:      12785
Logged by:          Daniele
Email address:      daniele.posenato <at> smartec.ch
PostgreSQL version: 9.3.3
Operating system:   W7 professionale 64 bit 
Description:        

Hi, 

For an industrial application I have the same software running on 4
different PCs with the same characteristics and configurations. Each PC has
its how postgresql database. All 4 PC are doing the same things.
On one PC sometimes (about one per week) I get the server process (PID 2872)
was terminated by exception 0xC0000005.

On the log file I have these information:
2015-02-13 22:46:05 CET LOG:  server process (PID 2872) was terminated by
exception 0xC0000005
2015-02-13 22:46:05 CET DETAIL:  Failed process was running: SELECT * FROM
highvaluelogs INNER JOIN (SELECT * FROM hvforeachpoint WHERE logID>0) AS
SQL1 ON highvaluelogs.logID=SQL1.logID ORDER BY highvaluelogs.logtimestamp
DESC;
2015-02-13 22:46:05 CET HINT:  See C include file "ntstatus.h" for a
description of the hexadecimal value.

I am not able to figure out way the query is able to crash the service. The
query is executed every 10 seconds and it is crashing the service only in
one PC. 
(Continue reading)

Alexey Klyukin | 19 Feb 12:07 2015

recurring SSL errors with streaming replication in 9.4.1

Hello,

We are getting period FATALs from our recently upgraded to 9.4.1 Hot Standby:

015-02-17 03:01:26.251 CET,,,30247,,54e1bfe0.7627,2,,2015-02-16
11:01:04 CET,,0,FATAL,XX000,"could not send data to WAL stream: SSL
error: unexpected record
",,,,,,,,,""
2015-02-17 03:01:26.280 CET,,,26192,,54dd0fb1.6650,12,,2015-02-12
21:40:17 CET,1/0,0,LOG,00000,"unexpected pageaddr 219/8B000000 in log
segment 00000004000002190000008F, offset 0",,,,,,,,,""
2015-02-17 03:01:26.295 CET,,,56544,,54e2a0f6.dce0,1,,2015-02-17
03:01:26 CET,,0,LOG,00000,"started streaming WAL from primary at
219/8F000000 on timeline 4",,,,,,,,,""

The issues happen roughly couple of times a day, but sometimes even
more frequently:

postgresql-2015-02-16_000000.csv:2015-02-16 11:01:04.093
CET,,,61385,,54de3bb7.efc9,2,,2015-02-13 19:00:23
CET,,0,FATAL,XX000,"could not send data to WAL stream: SSL error:
unexpected record
postgresql-2015-02-17_000000.csv:2015-02-17 03:01:26.251
CET,,,30247,,54e1bfe0.7627,2,,2015-02-16 11:01:04
CET,,0,FATAL,XX000,"could not send data to WAL stream: SSL error:
unexpected record
postgresql-2015-02-17_000000.csv:2015-02-17 19:01:39.693
CET,,,56544,,54e2a0f6.dce0,2,,2015-02-17 03:01:26
CET,,0,FATAL,XX000,"could not send data to WAL stream: SSL error:
unexpected record
(Continue reading)

gibheer | 18 Feb 20:27 2015

BUG #12784: pg_relation_size has problems with case in index name

The following bug has been logged on the website:

Bug reference:      12784
Logged by:          Stefan Radomski
Email address:      gibheer <at> zero-knowledge.org
PostgreSQL version: 9.4.1
Operating system:   FreeBSD 10.1p5
Description:        

I found a problem with indexes which have an uppercase letter in the name.
You can reproduce it with the following statements:

  create table unfindable("Test" text);
  create index on unfindable("Test");
  \d unfindable
  select pg_relation_size('unfindable_Test_idx');

It does work for tables with upper case characters in the name though.

--

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

patl659in | 18 Feb 16:45 2015

BUG #12782: Some abnormal observation about the to_date() function in greenplum database

The following bug has been logged on the website:

Bug reference:      12782
Logged by:          Rahul Patil
Email address:      patl659in <at> rediffmail.com
PostgreSQL version: Unsupported/Unknown
Operating system:   RHEL 6 64 bit
Description:        

Grennplum 4.3 64 bit

Incorrect output for to_date function
TESTDB=# select to_date('22-09-1990', 'MM-DD-YYYY');
to_date
------------
1991-10-11
(1 row)

Different output for same current_date function but with different format
TESTDB=# select to_date(current_date,'yyyy-mm-dd');
to_date
------------
2015-02-12
(1 row)
TESTDB=# select to_date(current_date,'dd-mm-yyyy');
to_date
------------
0017-08-07
(1 row)

(Continue reading)

Jeff Janes | 17 Feb 18:16 2015
Picon

Fwd: BUG #12772: Unexpected autovacuum behavior

On Sat, Feb 14, 2015 at 10:14 AM, <jd <at> ods.org> wrote:
The following bug has been logged on the website:

Bug reference:      12772
Logged by:          Jason DiCioccio
Email address:      jd <at> ods.org
PostgreSQL version: 9.3.6
Operating system:   Ubuntu 14.04 (Linux 3.13.0-40-generic)
Description:

Here's the situation I ran into:

autovacuum was vacuuming a large table in database 'db1' (to prevent txid
wraparound).  It turns out that one of the indexes of this table was
corrupted from the 9.3.4 WAL issue.  So VACUUM failed repeatedly.
Nonetheless, autovacuum kept trying.

Meanwhile in database 'db2', there were a number of tables in serious need
of vacuuming.  However, autovacuum would never touch these, even though
there were far less than autovacuum_max_workers running.  Other tables in
database 'db1' WERE being vacuumed, however.

So it appears that the logic is that autovacuum operates solely on one
database at a time.  Even if there is only one table that needs vacuuming in
that first database, it will not spawn any workers to vacuum tables that do
need vacuuming in a second database until it has completed vacuuming the
necessary tables from the first database.

This, to me, is unexpected behavior.  I'd expect autovacuum to not act as if
there were a large barrier between databases and to vacuum any table that
need it and that the configuration permits.

(Sorry, accidentally did not include the list on my original reply, here is a copy to the list)

 

This is a known issue, but so far there hasn't be a lot of urgency to fix it, probably because of a lack of complaints from the field until now, and because there are a few ways to address it and no one has forcefully advocated for one particular solution.

Basically it considers the database being in need of wrap around vacuum as an emergency (even thought it probably isn't) and funnels all future workers to it.  But when only one table is in need of that wrap around vacuum, all the other workers can't accomplish anything in that database, and other databases get starved.


Cheers,

Jeff

christoph.berg | 17 Feb 16:34 2015
Picon
Gravatar

BUG #12779: pg_dump -Fd doesn't care about -Z

The following bug has been logged on the website:

Bug reference:      12779
Logged by:          Christoph Berg
Email address:      christoph.berg <at> credativ.de
PostgreSQL version: 9.4.1
Operating system:   Linux (Debian 8)
Description:        

pg_dump -Fd doesn't seem to care about -Z for Z > 0:

$ for i in {0..9}; do echo $i; pg_dump -Z$i -Fd -f $i.fd postgres ; done
$ du ?.fd
5392	0.fd
1164	1.fd
1164	2.fd
1164	3.fd
1164	4.fd
1164	5.fd
1164	6.fd
1164	7.fd
1164	8.fd
1164	9.fd

In contrast with -Fc, where it works:

$ for i in {0..9}; do echo $i; pg_dump -Z$i -Fc -f $i.fc postgres ; done
$ du ?.fc
7548	0.fc
1488	1.fc
1440	2.fc
1392	3.fc
1240	4.fc
1148	5.fc
1160	6.fc
1156	7.fc
1160	8.fc
1160	9.fc

--

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

Jean-Pierre Pelletier | 16 Feb 03:48 2015
Picon

Exception 0xC0000005 on pg_restore with 9.4.1 at "copy from",works on 9.3.*

Hi,

This test case breaks "copy from" on 9.4.1 on Windows 7 & 8.1:

create function my_check_function(varchar) returns boolean as $$ begin return true; end; $$ language plpgsql immutable;

create table my_table (my_column integer);
alter table my_table add constraint my_check_constraint check(my_check_function(my_table::varchar));

copy (select 1) to 'c:\aaa\my_datafile1';
copy my_table from 'c:\aaa\my_datafile1'; -- Exception 0xC0000005

Jean-Pierre Pelletier

Gmane