Re: [BUGS] Known issues for PostgreSQL server 8.1.19

[Thomas Kellerer]

Dashputre, Anurag (GE Healthcare) wrote on 20.09.2013 08:39:

Thanks for your reply. We can't upgrade to newer version as of now. We just 
want to know list of known issues on 8.1.19.
We will just note them down and do some impact analysis.


You will need to go through the release notes for every version after 8.1.19 and see what 
was fixed - those should be the "open issues" in your release. An upgrade to a 
new minor version (8.1.19 to 8.1.23) should never be a problem though.


 





--
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] Cant start PostgreSQL Using command prompt

[Thomas Kellerer]

John R Pierce, 11.09.2013 19:19:
> btw, afaik Windows command prompt has no idea what & means.

No, that's not true.

See here for example:







-- 
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 #8394: SQL command REINDEX doesn't work

[Thomas Kellerer]

yzh...@trinityusa.com wrote on 23.08.2013 18:00:

The following bug has been logged on the website:

Bug reference:  8394
Logged by:  Yz Primus
Email address:  yzh...@trinityusa.com
PostgreSQL version: 9.1.3
Operating system:   Windows 7 64-bit
Description:

I always received error when trying to run SQL command REINDEX either from
pgAdmin III or psql. If I ran REINDEX DATABASE it threw error:
ERROR:  syntax error at end of input
LINE 1: REINDEX DATABASE


If I ran REINDEX DATABASE mydb it threw error:
ERROR:  can only reindex the currently open database


Quote from the manual:

  Presently, REINDEX DATABASE and REINDEX SYSTEM can only reindex the current 
database,
  so their parameter must match the current database's name.

So you need to specify the name of the current database even though it's not 
really needed.





--
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] Inconsistency between TO_CHAR() and TO_NUMBER()

[Thomas Kellerer]

Tom Lane wrote on 10.05.2013 17:49:

I looked into this, and find that the reason it misbehaves is that
NUM_numpart_from_char() will treat a '.' as being a decimal point
*without any regard to locale considerations*.  So even if we have
a locale-dependent format string and a locale that says '.' is a
thousands separator, it does the wrong thing.

It's a bit surprising nobody's complained of this before.

I propose the attached patch.  I'm slightly worried though about whether
this might break any existing applications that are (incorrectly)
depending on a D format specifier being able to match '.' regardless of
locale.  Perhaps we should only apply this to HEAD and not back-patch?


The manual claims that 'D' is locale dependent (whereas '.' is not), so
_theoretically_ a back patch would make sense I guess.






--
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 #8132: Not Null column should set default value when inserting or setting null

[Thomas Kellerer]

h...@lemcke.com wrote on 02.05.2013 10:18:

I would like to have the default value replace a given null value if the
column is specified with not null and default.

The SQL specification only requires to set the default value when the column
is omitted on insert or update.

I think this is a flaw in the specification because it requires developers
to create multiple statements for inserts and updates for all combinations
of default not null columns.


You can use DEFAULT instead of NULL, no need to have different statements.



--
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 #7967: Wrong week number in extract function

[Thomas Kellerer]

no...@noose.pl wrote on 18.03.2013 09:23:

The following bug has been logged on the website:

Bug reference:  7967
Logged by:  Pawel Kobylak
Email address:  no...@noose.pl
PostgreSQL version: 9.1.3
Operating system:   Debian
Description:

Hi,
I'm running that query and result is ... unexpected for me...

Query:
select '2012-12-31', EXTRACT(year from '2012-12-31'::date), EXTRACT(week
from '2012-12-31'::date)

Result:
"2012-12-31";2012;1

Expected:
"2012-12-31";2012;53
OR
"2012-12-31";2013;1

This result is correct? Or that is little bug? :-)
Regards,
Pawel


Expected - or at least documented.

You are looking for "isoyear" instead of "year":

select extract(isoyear from date '2012-12-31')
Result: 2013

The same "option" is available for the to_char() function: IYYY vs. 




--
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 #7851: Installer crash with message: An error occured executing the Microsoft VC++ runtimeinstaller

[Thomas Kellerer]

Ivano Luberti wrote on 06.02.2013 18:17:

Unfortunately the fix doesn't work because it seems the registry key is
protected even form administrator user modifications.

Even if you run regedit from a command prompt started as Administrator?


yes :-(



Probably the security settings for the corresponding registry key were changed.
But as you have an Administrator access, you should be able to reset the 
security settings.

In order to do that you need to run regedt32.exe (not regedit.exe)

Once you have found the key in question, you can right click and then choose 
"Security".
You'll get more or less the same dialog that is used to control file-system 
security.

Then give the Administrator the priviliges to delete/change those keys and you 
should be fine.

(Not sure if this still works the same under Windows 7 though).

Regards
Thomas




--
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 #7748: "drop owned by" fails with error message: "unrecognized object class: 1262"

[Thomas Kellerer]

Tom Lane wrote on 09.12.2012 17:43:

spam_ea...@gmx.net writes:

postgres=# create user testuser with password 'secret';
CREATE ROLE
postgres=# create database testdb owner testuser;
CREATE DATABASE
testdb=> drop owned by testuser;
ERROR:  unrecognized object class: 1262


I can reproduce this in all versions back to 8.3.  In 8.2, the role's
ownership of the database is silently ignored, which I think was the
design intention.  I doubt that we want DROP OWNED dropping whole
databases.  At most maybe we should raise a NOTICE?



Just for clarification, this is how it worked in 9.1 (and I'm pretty sure in 
9.2.1 as well):

First I create a testuser and the database:

C:\>psql -X -U postgres postgres
psql (9.1.3)

postgres=# create database testdb owner testuser;
ERROR:  role "testuser" does not exist
postgres=# create user testuser with password 'secret';
CREATE ROLE
postgres=# create database testdb owner testuser;
CREATE DATABASE
postgres=# \q

Then I log in as the testuser, create a table and drop all objects again:

C:\>psql -X -U testuser testdb
Password for user testuser:
psql (9.1.3)

testdb=> create table foobar (id integer);
CREATE TABLE
testdb=> drop owned by testuser;
DROP OWNED
testdb=>






--
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 #7748: "drop owned by" fails with error message: "unrecognized object class: 1262"

[Thomas Kellerer]

Tom Lane wrote on 09.12.2012 17:43:

spam_ea...@gmx.net writes:

postgres=# create user testuser with password 'secret';
CREATE ROLE
postgres=# create database testdb owner testuser;
CREATE DATABASE
testdb=> drop owned by testuser;
ERROR:  unrecognized object class: 1262


I can reproduce this in all versions back to 8.3.  In 8.2, the role's
ownership of the database is silently ignored, which I think was the
design intention.  I doubt that we want DROP OWNED dropping whole
databases.  At most maybe we should raise a NOTICE?



I don't want to drop the database, just all objects that are created by that 
user (tables, schemas, ...)
(In my example I first create a table)

And this has definitely worked before, otherwise my unit tests would have 
failed all the time.

Regards
Thomas




--
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 #7505: Backslash escaping not necessary

[Thomas Kellerer]

ovad...@gmail.com wrote on 24.08.2012 21:59:

The following bug has been logged on the website:

Bug reference:  7505
Logged by:  Jeff Ovadya
Email address:  ovad...@gmail.com
PostgreSQL version: 9.1.4
Operating system:   PostgreSQL 9.1.4, compiled by Visual C++ build 150
Description:

Also noticed similar issue escaping single quotes: Backslash will not work
to escape, but doubling up the quotes works.


Which is the correct behaviour and conforms to the SQL standard (and nearly all 
other DBMS behave the same way)

But if you want to use the backslash to escape single quotes check out the 
parameter
"standard_conforming_strings" which controls this behaviour:

http://www.postgresql.org/docs/9.1/static/runtime-config-compatible.html#GUC-STANDARD-CONFORMING-STRINGS






--
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 #6742: pg_dump doesn't convert encoding of DB object names to OS encoding

[Thomas Kellerer]

exclus...@gmail.com, 18.07.2012 09:17:

The following bug has been logged on the website:

Bug reference:  6742
Logged by:  Alexander LAW
Email address:  exclus...@gmail.com
PostgreSQL version: 9.1.4
Operating system:   Windows
Description:

When I try to dump database with UTF-8 encoding in Windows, I get unreadable
object names.
Please look at the screenshot (http://oi50.tinypic.com/2lw6ipf.jpg). On the
left window all the pg_dump messages displayed correctly (except for the
prompt password (bug #6510)), but the non-ASCII object name is gibberish. On
the right window (where dump is done with the Windows 1251 encoding (OS
Encoding for Russian locale)) everything is right.


Did you check the dump file using an editor that can handle UTF-8?
The Windows console is not known for properly handling that encoding.

Thomas




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

[BUGS] Documentation bug regarding collations

[Thomas Kellerer]

in the description of the ORDER BY clause 
(http://www.postgresql.org/docs/current/static/sql-select.html#SQL-ORDERBY) it 
says:

"Character-string data is sorted according to the locale-specific collation order 
that was established when the database was created."

Which is no longer true with 9.1 as it is possible to define the collation on a 
per-column basis or as part of the ORDER BY clause.

I think a link to the collation chapter and a description on the "precedence" 
of the definitions should be added to that part.

Regards
Thomas




--
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] Weird message when creating PK constraint named like table

[Thomas Kellerer]

Kevin Grittner, 11.01.2012 21:16:

When I do this

CREATE TABLE "*T1*"
(
   "T1_ID" bigint NOT NULL,
   CONSTRAINT "*T1*" PRIMARY KEY ("T1_ID" )
);


I get the following message:

NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"T1" for table "T1"
ERROR:  relation "T1" already exists



SQL state: 42P07


Hmm.  If I create them with the asterisks as part of the relation
names, I see the asterisks in the messages:

NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"*T1*" for table "*T1*"
ERROR:  relation "*T1*" already exists



The * around the table name was added by the translation from the HTML to a 
plain text email.

If you display the HTML version of the original posting the name is written in bold, and 
I gues the plain text "converter" simply adds the asterisks as that is the 
usual convention for bold in plain text emails.

The original SQL is:

CREATE TABLE "T1"
(
  "T1_ID" bigint NOT NULL,
  CONSTRAINT "T1" PRIMARY KEY ("T1_ID" )
);



--
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] char(0)

[Thomas Kellerer]

Susanne Ebrecht, 17.10.2011 09:31:

Hello,

I couldn't find that somebody already mentioned it.

PostgreSQL isn't supporting CHAR(0).

An empty string has a length of 0.

CHAR(0) can have two values: NULL and empty string.

In MySQL it is very common to simulate not null boolean
by using CHAR(0).

This is a little bit annoying on migration topics.


While not move on to a cleaner approach during the migration and use a "boolean not 
null"?

Thomas



--
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] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe

[Thomas Kellerer]

Dave Page, 04.10.2011 21:46:

We updated our build system to use BitRock 7 today (for unrelated
reasons) which has new features for ACL management. We're going to
investigate replacing cacls/icacls with those features tomorrow and
will create some test builds ASAP.


If you can provide the test builds publicly, I will be happy to test them and 
see if that behaves differently on my system.

Regards
Thomas

 




--
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] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe

[Thomas Kellerer]

Dave Page wrote on 03.10.2011 10:11:

Karl; can you please provide precise details of your Windows version,
and anything unusual about your disk configuration? I know this
doesn't happen on any of the installations of Windows 7 that we use
for testing (which tend to be the MSDN builds, running on local NTFS
disks), so I wonder if there's an icacls bug in a specific build or
rev of Windows, or when used on a certain type of filesystem.




I have reported this as well some weeks ago.
For me this happened on a Windows7 64 bit system that is part of a domain (all 
current MS patches applied)
UAC is turned off, I was logged in as a local administrator (*not* a domain 
administrator).

I have a ProcessMonitor trace that shows the behaviour of what icacls is doing 
when started by the installer.
It is available here: http://www.sql-workbench.net/icacls_trace.zip

Regards
Thomas


--
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 #5348: Postgres crashes with index on xpath_string

[Thomas Kellerer]

Thanks for the feedback.

Is the problem specific to 8.4.2 or to the Windows platform (or both)?

Regards
Thomas


Bruce Momjian, 27.02.2010 18:42:


Yes, we have received a few reports about this and are working on a fix.

---

Thomas Kellerer wrote:


The following bug has been logged online:

Bug reference:  5348
Logged by:  Thomas Kellerer
Email address:  tho...@kellerer.name
PostgreSQL version: 8.4.2
Operating system:   Windows XP
Description:Postgres crashes with index on xpath_string
Details:

With the contrib module xml2 (pgxml.sql) installed, run the following
script:

create table t1 (id integer, xml_data xml);
insert into t1 (id, xml_data)
values
(1, 'Some
Value');

create index idx_xpath on t1 ( xpath_string
('/attributes/attribu...@name="attr_1"]/text()', xml_data::text));

This will crash the backend.

The entry in the logfile is:

2010-02-27 17:21:28 CET STATEMENT:  create index idx_xpath on t1 (
xpath_value ('/attributes/attribu...@name="attr_1"]/text()',
xml_data::text))
2010-02-27 17:21:55 CET LOG:  server process (PID 2544) was terminated by
exception 0xC005
2010-02-27 17:21:55 CET HINT:  See C include file "ntstatus.h" for a
description of the hexadecimal value.
2010-02-27 17:21:55 CET LOG:  terminating any other active server processes
2010-02-27 17:21:55 CET LOG:  all server processes terminated;
reinitializing


When restarting the server, the following messages are written to the
logfile:


2010-02-27 17:22:05 CET FATAL:  pre-existing shared memory block is still in
use
2010-02-27 17:22:05 CET HINT:  Check if there are any old server processes
still running, and terminate them.
2010-02-27 17:22:22 CET LOG:  database system was interrupted; last known up
at 2010-02-27 16:22:32 CET
2010-02-27 17:22:22 CET LOG:  database system was not properly shut down;
automatic recovery in progress
2010-02-27 17:22:22 CET LOG:  redo starts at 3/B77FAB28
2010-02-27 17:22:22 CET LOG:  unexpected pageaddr 3/9585 in log file 3,
segment 183, offset 8716288
2010-02-27 17:22:22 CET LOG:  redo done at 3/B784F758
2010-02-27 17:22:22 CET LOG:  last completed transaction was at log time
2010-02-27 17:21:20.382+01
2010-02-27 17:22:23 CET FATAL:  the database system is starting up
2010-02-27 17:22:23 CET LOG:  database system is ready to accept
connections
2010-02-27 17:22:24 CET LOG:  autovacuum launcher started


When the following index is created, things seem to work (at least the
backend is not crashing)

create index idx_xpath on t1 ( xpath_string
('/attributes/attribu...@name="attr_1"]', xml_data::text))

(note the missing text() in the xpath)

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




--
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 #5348: Postgres crashes with index on xpath_string

[Thomas Kellerer]

The following bug has been logged online:

Bug reference:  5348
Logged by:  Thomas Kellerer
Email address:  tho...@kellerer.name
PostgreSQL version: 8.4.2
Operating system:   Windows XP
Description:Postgres crashes with index on xpath_string
Details: 

With the contrib module xml2 (pgxml.sql) installed, run the following
script:

create table t1 (id integer, xml_data xml);
insert into t1 (id, xml_data)
values
(1, 'Some
Value');

create index idx_xpath on t1 ( xpath_string
('/attributes/attribu...@name="attr_1"]/text()', xml_data::text));

This will crash the backend. 

The entry in the logfile is:

2010-02-27 17:21:28 CET STATEMENT:  create index idx_xpath on t1 (
xpath_value ('/attributes/attribu...@name="attr_1"]/text()',
xml_data::text))
2010-02-27 17:21:55 CET LOG:  server process (PID 2544) was terminated by
exception 0xC005
2010-02-27 17:21:55 CET HINT:  See C include file "ntstatus.h" for a
description of the hexadecimal value.
2010-02-27 17:21:55 CET LOG:  terminating any other active server processes
2010-02-27 17:21:55 CET LOG:  all server processes terminated;
reinitializing


When restarting the server, the following messages are written to the
logfile:


2010-02-27 17:22:05 CET FATAL:  pre-existing shared memory block is still in
use
2010-02-27 17:22:05 CET HINT:  Check if there are any old server processes
still running, and terminate them.
2010-02-27 17:22:22 CET LOG:  database system was interrupted; last known up
at 2010-02-27 16:22:32 CET
2010-02-27 17:22:22 CET LOG:  database system was not properly shut down;
automatic recovery in progress
2010-02-27 17:22:22 CET LOG:  redo starts at 3/B77FAB28
2010-02-27 17:22:22 CET LOG:  unexpected pageaddr 3/9585 in log file 3,
segment 183, offset 8716288
2010-02-27 17:22:22 CET LOG:  redo done at 3/B784F758
2010-02-27 17:22:22 CET LOG:  last completed transaction was at log time
2010-02-27 17:21:20.382+01
2010-02-27 17:22:23 CET FATAL:  the database system is starting up
2010-02-27 17:22:23 CET LOG:  database system is ready to accept
connections
2010-02-27 17:22:24 CET LOG:  autovacuum launcher started


When the following index is created, things seem to work (at least the
backend is not crashing)

create index idx_xpath on t1 ( xpath_string
('/attributes/attribu...@name="attr_1"]', xml_data::text))

(note the missing text() in the xpath)

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