[BUGS] BUG #4400: initdb doesn't work with partition D:
The following bug has been logged online: Bug reference: 4400 Logged by: Jan-Peter Seifert Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.3 Operating system: Windows xp Professional Description:initdb doesn't work with partition D: Details: Hello, whenever I try to run initdb on a directory on partition "D:" with the parameter "-D" I get the error that a "file exists". I create a directory, give full rights for the user postgres and then run initdb on it. On partition E: it works. Both are NTFS. I have no programs open that might access the directories ... Strange. -- 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 #4582: Renaming sequences and default value
The following bug has been logged online:
Bug reference: 4582
Logged by: Jan-Peter Seifert
Email address: jan-peter.seif...@gmx.de
PostgreSQL version: 8.3.5
Operating system: Windows xp
Description:Renaming sequences and default value
Details:
Hello PostgreSQL-Team,
there's a problem with renaming sequences in our databases. It seems to be
connected to the nextval 'syntax'.
We detected it during testing a script to correct 'broken connections'
between a serial column and its sequence.
When I try to rename 'old' sequences:
ALTER SEQUENCE t1_id_seq RENAME TO ___t1_id_seq;
everything is fine and both nextval and owned by are updated.
When I try the same on a different sequence neither owned by nor nextval are
updated.
ALTER SEQUENCE t2_id_seq RENAME TO ___t2_id_seq;
In pgAdmin (1.8.4 and server binaries) the create command for the first
table looks like this:
CREATE TABLE t1
(
dbef character varying(6),
ansc_id serial NOT NULL
.
.
.
)
The create command for the failing table/sequence looks like this:
CREATE TABLE t2
(
dbef character varying(6),
id integer NOT NULL DEFAULT nextval(('public.t2_id_seq'::text)::regclass)
.
.
.
)
The displayed create table command changed after inserting the column dbef
before the serial column into the already existing table. Before that the
create command looked the same ...
The Properties of the columns differ in the following way:
ALTER TABLE t1 ALTER COLUMN id SET DEFAULT nextval('t1_id_seq'::regclass);
ALTER TABLE t2 ALTER COLUMN id SET DEFAULT
nextval(('public.t2_id_seq'::text)::regclass);
When I change the table t2's nextval command to that from table t1 the
renaming of the sequence correctly causes an update of owned by and
nextval.
The first symptom was that the owned by connection between serial column and
sequence got lost - obviously due to inserting the new column. The
additional text cast to nextval does seem to cause a problem.
We had another problem with sequences as well that might be connected.
Unfortunately the logs weren't kept and it happened at random. After
renaming tables like: 'table' to '__table' and back to 'table' (without
quotes) there were sequences left with an underscore although our update
tool is not supposed to show this behaviour and PostgreSQL neither.
Thank you very much in advance,
Peter Seifert
--
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 #4582: Renaming sequences and default value
Tom Lane wrote:
Thank you very much for your quick reply. I wanted to do some testing
before reporting back.
> "Jan-Peter Seifert" writes:
>> there's a problem with renaming sequences in our databases.
>
> I don't think there's really a problem here. You've apparently got some
> obsolete syntax in your CREATE commands:
>
>> id integer NOT NULL DEFAULT nextval(('public.t2_id_seq'::text)::regclass)
>
> This specifically says that 'public.t2_id_seq' is a string (text) constant,
> which is not going to change in response to anything. If you would
> like it to track renamings of the sequence then it needs to be a
> regclass constant:
>
> id integer NOT NULL DEFAULT nextval('public.t2_id_seq'::regclass)
At first I thought the reason why a renamed sequence couldn't be found
via nextval anymore - even with 'owned by' set - was evaluating the
'historical' adsrc and not the adbin column in pg_attrdef within the
maintenance script. But then I saw the difference in nextval syntax
etc.. The update tool in question uses the obsolete syntax. Has this
text constant thing been official syntax for some time? I wonder why the
person implementing this syntax into the tool did it in the first place.
Now after changing the nextval syntax with an ALTER TABLE as well all
seems to be alright again. Even pgAdmin III now shows 'serial' as data
type for the column again.
> Also, neither of these forms will by itself establish an OWNED BY
> relationship --- you'll need a separate ALTER SEQUENCE OWNED BY
> command if you want that.
Thank you very much for pointing this out. We only discovered it after
looking through a dump some time ago.
Peter Seifert
--
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 #4863: postgresql.conf typo in log_line_prefix
The following bug has been logged online: Bug reference: 4863 Logged by: Jan-Peter Seifert Email address: jan-peter.seif...@gmx.de PostgreSQL version: 8.4 RC1 Operating system: Windows Description:postgresql.conf typo in log_line_prefix Details: log_line_prefix is set to '%%t' So it shows '%t' instead of a time stamp. P.S. Where can I ask questions about the changes from the first/second beta in: lc_monetary (lc_ etc.): 'German, Germany' instead of 'German_Germany.1252' default_text_search_config: 'pg_catalog.simple' instead of 'pg_catalog.german' Why is log_min_messages set to warning by default in 8.4? Thank you very much, Peter -- 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 #3964: Parsing error in Stack Builder with LATIN1 client encoding
The following bug has been logged online: Bug reference: 3964 Logged by: Jan-Peter Seifert Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.0 Operating system: Windows xp sp2 German Description:Parsing error in Stack Builder with LATIN1 client encoding Details: When choosing LATIN1 instead of the default CP1252 for the client encoding I get this error in PostgreSQL & EnterpriseDB Stack Builder: 13:42:54: Fehler beim Lesen des XML: 'syntax error' in Zeile 1 13:42:54: Konnte die Anwendungsliste nicht parsen: http://www.postgresql.org/applications.xml It doesn't matter whether the server encoding is LATIN1 or not. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #4098: Encoding problems
The following bug has been logged online: Bug reference: 4098 Logged by: Jan-Peter Seifert Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Windows xp Description:Encoding problems Details: The encoding of the source db/server is LATIN1. The data type of the field is text (The storage mode is extended). It's/was possible to add characters available in CP1252 but not in LATIN1 like the Euro character (code 80). When exporting to UTF8 via "pg_dump -o -U postgres -E UTF-8 ..." (iconv?) it just adds the character with the code "C2" before the Euro character in the dump. When importing the dump to a server/db with CP1252 it just throws an error because of the inconvertible character (0xc280) and seems to stop with no further error messages (at least the whole table in question is empty although filled in the source db). It wasn't an issue before the restrictions were put in place, because the C locale is insufficient. -- 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 #5874: pg_dumpall CREATE DATABASE statements 'missing' parameters
The following bug has been logged online: Bug reference: 5874 Logged by: Jan-Peter Seifert Email address: jan-peter.seif...@gmx.de PostgreSQL version: 8.4.7 Operating system: Windows 7 64-Bit Description:pg_dumpall CREATE DATABASE statements 'missing' parameters Details: Hello, it's not really a bug ... but CREATE DATABASE statements for databases with the same Locale/Encoding as the server miss the parameters ENCODING, LC_COLLATE and LC_CTYPE. So you 'can't' migrate to a server with a different Locale/Encoding setting. I'd be very happy if one had the option to switch between OS specific names e.g. German_Germany.28591 on Windows and de_DE on Linux automatically ( -b WIN ) or manually ( -w German_Germany.28591,de_DE+...) as well. I'd also be very happy if one could specify a comma separated list of databases to skip (e.g. template1, postgres etc.) Thank you very much, Peter -- 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 #5878: BTREE_BUILD_STATS causes 'make check' to fail
The following bug has been logged online: Bug reference: 5878 Logged by: Jan-Peter Seifert Email address: jan-peter.seif...@gmx.de PostgreSQL version: 8.4.7 Operating system: Ubuntu 10.04 LTS Description:BTREE_BUILD_STATS causes 'make check' to fail Details: Hello, I experimented a bit with compiling PostgreSQL with debug macros. I set up a Makefile.custom with the following contents: CFLAGS+=-DLOCK_DEBUG CFLAGS+=-DBTREE_BUILD_STATS CFLAGS+=-DWAL_DEBUG However, as long as I have BTREE_BUILD_STATS defined, 'make check' fails on me with the following message: ... btree.c: In function ‘btbuild’: nbtree.c:100: error: ‘log_btree_build_stats’ undeclared (first use in this function) nbtree.c:100: error: (Each undeclared identifier is reported only once nbtree.c:100: error: for each function it appears in.) nbtree.c:101: warning: implicit declaration of function ‘ResetUsage’ nbtree.c:146: warning: implicit declaration of function ‘ShowUsage’ ... Without this macro the server seems to install nicely. Am I just doing something wrongly - I'm not really familiar with gcc? Thank you very much, Peter -- 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 #6274: documentation on pg_attribute.atttypmod
The following bug has been logged online: Bug reference: 6274 Logged by: Jan-Peter Seifert Email address: jan-peter.seif...@gmx.de PostgreSQL version: 9.1 Operating system: any Description:documentation on pg_attribute.atttypmod Details: Hello, it looks like that the remarks on column pg_attribute.atttypmod haven't been updated for a while: http://www.postgresql.org/docs/current/interactive/catalog-pg-attribute.html It obviously does contain the actual value ( possibly changed by ALTER TABLE ... ). With best regards, Peter -- 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 #6722: Debugger broken?
The following bug has been logged on the website: Bug reference: 6722 Logged by: Jan-Peter Seifert Email address: jan-peter.seif...@gmx.de PostgreSQL version: 9.1.4 Operating system: Windows 7 Enterprise (64-bit) Description: Hello, it seems that the debugger doesn't work with current minor versions of PostgreSQL. I don't even get the debugging option shown here: http://stackoverflow.com/questions/7865615/debug-postgresql-function-using-pgadmin It could be connected to these changes: http://git.postgresql.org/gitweb/?p=pldebugger.git;a=log I activated the debugger in postgresql.conf and restarted the server(s)): shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll' As there only exists the contrib-script I tried to execute this: c:\Program Files\PostgreSQL\9.1\share\contrib\pldbgapi.sql I only get a function not found ( in debugger.dll ) error: FEHLER: konnte Funktion »plpgsql_oid_debug« nicht in Datei »C:/Program Files/PostgreSQL/9.1/lib/plugins/plugin_debugger.dll« finden SQL Status:42883 If I switch to this it works: CREATE OR REPLACE FUNCTION pldbg_oid_debug( OID ) RETURNS INTEGER AS '$libdir/plugins/plugin_debugger' LANGUAGE C STRICT; It's the same with 8.4.12 ( 32-bit ) and 9.0.8 ( 64-bit ). It's the very same install script for each version. In 8.4.12 I also have these two files: c:\Program Files (x86)\PostgreSQL\8.4\share\contrib\pldbgapi--1.0.sql and c:\Program Files (x86)\PostgreSQL\8.4\share\contrib\pldbgapi--unpackaged--1.0.sql Obviously they are for PostgreSQL 9.1. The first says install with 'CREATE EXTENSION pldbgapi' There's no such extension - neither in Windows nor Ubuntu ( One click installer and aptitude ) nor in the docs. With best regards, Peter -- 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 #7820: Extension uuid-ossp cannot be installed on Windows - getting syntax error
The following bug has been logged on the website: Bug reference: 7820 Logged by: Jan-Peter Seifert Email address: jan-peter.seif...@gmx.de PostgreSQL version: 9.1.7 Operating system: Windows 7 64-bit Description: The statement: 'CREATE EXTENSION uuid-ossp' just gives me a syntax error: ERROR: syntax error at or near "-" LINE 1: CREATE EXTENSION uuid-ossp ^ ** Fehler ** ERROR: syntax error at or near "-" SQL Status:42601 Zeichen:22 Obviously "CREATE EXTENSION" expects underscores instead of hyphens. I had to replace the hyphen in file names and in the scripts to make the module work. -- 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 #7820: Extension uuid-ossp cannot be installed on Windows - getting syntax error
Am 22.01.2013 14:47, schrieb Marc Balmer: > no. Your syntax is wrong. Well - it's not exactly 'my' syntax - see: uuid-ossp--1.0.sql uuid-ossp--unpackaged--1.0.sql >> I had to replace the hyphen in file names and in the scripts to make the >> module work. >> > That is the wrong "fix". The hyphen has a meaning in SQL. So you need to > properly enclose uuid-ossp in quotes. I didn't think about the fact that extensions are database objects, too. It's a bit annoying that this extension has non-standard characters in its name though. It's the only one from all that currently exist. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
