[BUGS] BUG #2284: missing sequence number
The following bug has been logged online: Bug reference: 2284 Logged by: Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.2 Operating system: linux Description:missing sequence number Details: if the server shuts down abrupotly because of power failuar or any other cause then the sequences tend to skip few numbers. After restarting the postgresql server the nextval of sequence doest match with the last number. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2286: Wrong index creation with cs_CZ locales and HYPHEN
The following bug has been logged online:
Bug reference: 2286
Logged by: David Sauer
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.2, 8.1.3
Operating system: Linux (libc6), debian
Description:Wrong index creation with cs_CZ locales and HYPHEN
Details:
I have table:
CREATE TABLE m (i TEXT);
CREATE INDEX myidx ON m(i);
... INSERT about 2000 values INTO m in the form
INSERT INTO m VALUES ('some-hack-1');
INSERT INTO m VALUES ('some-hack-2');
INSERT INTO m VALUES ('some-hack-3');
INSERT INTO m VALUES ('some-hack-4');
... approx 2000 values with 'HYPHEN' (-)
VACUUM FULL ANALYZE;
now, the query:
SELECT * FROM m WHERE i = 'some-hack-4';
finds nothing ...
but:
SELECT * FROM m WHERE i || '' = 'some-hack-4';
finds expected row (but without index use, so it is slow).
The problem is between libc6 2.3.2 and libc6 2.3.6, definition files are
stored at:
http://img.123shop.cz/gimg/Popis/a.zip
Problem is probably in libc6 locales, but postgresql developer knows more
about libc6 ... (not true in opposite direction ?)
I'am running current version of debian linux, postgres 8.1.2 or 8.1.3
compiled myself. Feel free to contact me for more details.
Thank You,
David Sauer
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2283: VS .NET 2003 connection problem
The following bug has been logged online: Bug reference: 2283 Logged by: Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Windows XP Home Edition SP2 Description:VS .NET 2003 connection problem Details: Hello, In Visual Studio .NET 2003, I use PostgreSQL OLE DB Provider to connect to PostgreSQL 8.1 database. When I create a Data connection, an error occures messaging that "Not enough storage is available to complete this operation" How can I establish the connection? Thank you in advance. Regards, Frixos ---(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 #2285: Can not access database after successful PITR - file naming problems
The following bug has been logged online: Bug reference: 2285 Logged by: Nicholas Vinen Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Gentoo Linux x86 Description:Can not access database after successful PITR - file naming problems Details: For debugging/testing purposes, I have taken to performing a PITR on a test machine from the production database back-ups. I restore a snap-shot of the production server which was taken before the time I am interested in debugging, then use the PITR method to get the database to the point I want to test at. I can then "rewind" the database and test again by restoring again. This used to work (either before 8.0 or before 8.1, I'm not sure). I also have this back-up in case the production database server dies, but can't really test restoring it on the production machine except when data is lost, otherwise I will interrupt service. The machines are almost identical, the only real difference is that one is a Pentium 3 and one is a Pentium 4, so I don't see why that should matter. They are both running virtually identical Linux installations. Now, when I try to use PITR to restore the database on my test server, the PITR succeeds as normal, but I can not access the database with an error like: psql: FATAL: could not open relation 1663/16385/605464: No such file or directory This happens when I attempt to connect to my database. I can connect to some of the others (such as the template databases) fine. Interestingly, the 605464 file was in the back-up snapshot, but the process of performing the PITR seems to rename the file, but it's still looking under the old name. This is fully reproducible, so if I am not providing sufficient information here, just let me know what you need in order to fix this. Here is a log of what I have done up to the error: rt2 ~ # cd /var/lib/postgresql/data rt2 data # rm -rf * rt2 data # gzip -cd /backup/Helpdesk/Database/Snapshots/Weekly/2006-06\ \ Sun\ 12\ Feb.io.gz | cpio -i 3229320 blocks rt2 data # ls -al base/16385/605464 -rw--- 1 postgres postgres 40960 Feb 27 02:57 base/16385/605464 rt2 data # rm pg_xlog/* rm: cannot remove `pg_xlog/archive_status': Is a directory rt2 data # cp /data/postgresql/recovery.conf /data/postgresql/postgresql.conf . rt2 data # chown postgres * rt2 data # /etc/init.d/postgresql start * Starting PostgreSQL ... rt2 data # tail -f /var/log/postgres/current Feb 27 03:06:12 [postgres] [1-1] LOG: could not create IPv6 socket: Address family not supported by protocol Feb 27 03:06:12 [postgres] [2-1] LOG: database system was interrupted at 2006-02-12 01:30:02 PST Feb 27 03:06:12 [postgres] [3-1] LOG: starting archive recovery Feb 27 03:06:12 [postgres] [4-1] LOG: restore_command = "gzip -cd /backup/Helpdesk/Database/TransactionLog/"%f">"%p"" Feb 27 03:06:12 [postgres] [5-1] LOG: recovery_target_time = 2006-02-17 08:20:00-08 Feb 27 03:06:12 [postgres] [6-1] LOG: restored log file "0001000B0002.00A9FA60.backup" from archive Feb 27 03:06:14 [postgres] [7-1] LOG: restored log file "0001000B0002" from archive Feb 27 03:06:14 [postgres] [8-1] LOG: checkpoint record is at B/2A9FA60 Feb 27 03:06:14 [postgres] [9-1] LOG: redo record is at B/2A9FA60; undo record is at 0/0; shutdown FALSE Feb 27 03:06:14 [postgres] [10-1] LOG: next transaction ID: 34066581; next OID: 611376 Feb 27 03:06:14 [postgres] [11-1] LOG: next MultiXactId: 633; next MultiXactOffset: 1265 Feb 27 03:06:14 [postgres] [12-1] LOG: automatic recovery in progress Feb 27 03:06:14 [postgres] [13-1] LOG: redo starts at B/2A9FAA4 Feb 27 03:06:27 [postgres] [14-1] LOG: restored log file "0001000B0003" from archive Feb 27 03:06:38 [postgres] [15-1] LOG: restored log file "0001000B0004" from archive Feb 27 03:06:41 [postgres] [16-1] LOG: restored log file "0001000B0005" from archive Feb 27 03:47:13 [postgres] [682-1] LOG: restored log file "0001000D00A1" from archive Feb 27 03:47:17 [postgres] [683-1] LOG: restored log file "0001000D00A2" from archive Feb 27 03:47:21 [postgres] [684-1] LOG: restored log file "0001000D00A3" from archive Feb 27 03:47:21 [postgres] [685-1] LOG: recovery stopping before commit of transaction 42586328, time 2006-02-17 08:20:01 PST Feb 27 03:47:21 [postgres] [686-1] LOG: redo done at D/A35794EC Feb 27 03:47:21 [postgres] [687-1] LOG: selected new timeline ID: 2 Feb 27 03:47:22 [postgres] [688-1] LOG: archive recovery complete Feb 27 03:47:32 [postgres] [689-1] LOG: database system is ready Feb 27 03:47:32 [postgres] [690-1] LOG: transaction ID wrap limit is 1103292637, limited by database "postgres" Feb 27 05:39:54 [postgres] [2-1] LOG: invalid server process ID -1 (new error in 8.1.3) rt2 data # psql -U postgres rt3 psql: FATAL: could not open relation 1663/16385/605464: No such file or directory rt2 data # ls -al base/16385/605464 rt2 data #
Re: [BUGS] BUG #2284: missing sequence number
[EMAIL PROTECTED] wrote: > if the server shuts down abrupotly because of power failuar or any other > cause then the sequences tend to skip few numbers. > After restarting the postgresql server the nextval of sequence doest match > with the last number. This is per design, i.e. not a bug. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2284: missing sequence number
On Mon, Feb 27, 2006 at 11:52:19AM +, [EMAIL PROTECTED] wrote: > if the server shuts down abrupotly because of power failuar or any other > cause then the sequences tend to skip few numbers. > After restarting the postgresql server the nextval of sequence doest match > with the last number. http://www.postgresql.org/docs/faqs.FAQ.html#item4.11.4 -- Michael Fuhr ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2286: Wrong index creation with cs_CZ locales and HYPHEN
"David Sauer" <[EMAIL PROTECTED]> writes: > PostgreSQL version: 8.1.2, 8.1.3 > Operating system: Linux (libc6), debian > Description:Wrong index creation with cs_CZ locales and HYPHEN You've probably gotten bit by the 8.1.2 changes in locale-dependent sorting. Try REINDEXing the affected indexes, as per the 8.1.2 release notes. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2285: Can not access database after successful PITR - file naming problems
"Nicholas Vinen" <[EMAIL PROTECTED]> writes: > Now, when I try to use PITR to restore the database on my test server, the > PITR succeeds as normal, but I can not access the database with an error > like: > psql: FATAL: could not open relation 1663/16385/605464: No such file or > directory This seems pretty ugly :-(. Unless you've got some odd stuff in ~/.psqlrc, I would think that psql startup could only cause accesses to system catalogs, but 605464 is far beyond the normal relfilenode numbers assigned to any system catalogs or indexes. AFAICS the only way that a new relfilenode would be assigned is during TRUNCATE, CLUSTER or REINDEX ... have you done any of those on system catalogs? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] has_table/schema_privilige() returns incorrect info on temp tables
Hi,
While running 2 sessions in different terminals for the same user, what
happens in the second session here looks a bit weird:
=
=
db=# create temp table t_test (id int);
CREATE TABLE
db=# select table_schema from information_schema.tables
where table_name = 't_test';
table_schema
--
pg_temp_2
(1 row)
db=# select has_schema_privilege('pg_temp_2', 'usage');
has_schema_privilege
--
t
(1 row)
db=# select has_table_privilege('pg_temp_2.t_test', 'insert');
has_table_privilege
-
t
(1 row)
db=# select has_table_privilege('t_test', 'insert');
has_table_privilege
-
t
(1 row)
db=# insert into t_test values (1);
INSERT 0 1
=
=
db=# select table_schema from information_schema.tables
where table_name = 't_test';
table_schema
--
pg_temp_2
(1 row)
db=# select has_schema_privilege('pg_temp_2', 'usage');
has_schema_privilege
--
t
(1 row)
db=# select has_table_privilege('pg_temp_2.t_test', 'insert');
has_table_privilege
-
t
(1 row)
db=# select has_table_privilege('t_test', 'insert');
ERROR: relation "t_test" does not exist
db=# insert into t_test values (1);
ERROR: relation "t_test" does not exist
db=# select version();
version
PostgreSQL 8.1.3 on i586-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3
(1 row)
In this light, is there a possibility to find out what schema will be used for
temporary tables created during the current session? I need to find out
whether a specific temporary table exists and is accessible for the current
user in the current session.
--
Best,
Frank.
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [BUGS] has_table/schema_privilige() returns incorrect info on temp tables
Frank van Vugt <[EMAIL PROTECTED]> writes:
> While running 2 sessions in different terminals for the same user, what
> happens in the second session here looks a bit weird:
In the first place, you are evidently running as superuser, which means
that has_foo_privilege will ALWAYS say 't' (except possibly if the
target object doesn't exist, in which case I think you get an error).
In the second place, trying to access another session's temp table is
unsupported.
> In this light, is there a possibility to find out what schema will be used
> for
> temporary tables created during the current session?
After you've created at least one temp table, you can look at the result
of "current_schemas(true)". There's no guarantee that the schema even
exists before you've created something...
regression=# select current_schemas(true);
current_schemas
-
{pg_catalog,public}
(1 row)
regression=# create temp table t(f1 int);
CREATE TABLE
regression=# select current_schemas(true);
current_schemas
---
{pg_temp_1,pg_catalog,public}
(1 row)
regression=# select (current_schemas(true))[1];
current_schemas
-
pg_temp_1
(1 row)
regression=#
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] has_table/schema_privilige() returns incorrect info on temp tables
Hi, > In the first place, you are evidently running as superuser, which means > that has_foo_privilege will ALWAYS say 't' Ok, seems reasonable ;) > (except possibly if the > target object doesn't exist, in which case I think you get an error). Yep, one does. > In the second place, trying to access another session's temp table is > unsupported. I understand, it's more the opposite, I was fixing a bug in a plpgsql function that would fail when the user has created a certain (temporary) table in a second session, because the code only checked the existence of the table_name without taking into account the proper schema. > After you've created at least one temp table, you can look at the result > of "current_schemas(true)". There's no guarantee that the schema even > exists before you've created something... Got that, looks like an acceptable workaround in this case, though. Is there a guaranteed order of the resulting array, i.e. is this guaranteed to return the temp schema, given there is one: 'select (current_schemas(true))[1]'.? (obviously, regexp's will also do the trick, I'm just asking) -- Best, Frank. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] has_table/schema_privilige() returns incorrect info on temp tables
Frank van Vugt <[EMAIL PROTECTED]> writes: >> After you've created at least one temp table, you can look at the result >> of "current_schemas(true)". There's no guarantee that the schema even >> exists before you've created something... > Is there a guaranteed order of the resulting array, i.e. is this guaranteed > to > return the temp schema, given there is one: > 'select (current_schemas(true))[1]'.? Yes, in the current implementation and for the foreseeable future (else temp tables would fail to mask permanent tables). regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2287: Probably a translation error
The following bug has been logged online: Bug reference: 2287 Logged by: Tanguy MOAL Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.7 Operating system: Linux Fedora Core 4 Description:Probably a translation error Details: When using the interactive mode : Using the french locale: Using online help \h delete Systems answers : Commande : DELETE Description : supprimer des colonnes dans une table [...] - Which means 'delete columns from a table' instead of Description : supprimer des lignes dans une table - Which means 'delete lines from a table' ... I hope it was clear, that's just an error of translation, it is not critical. :) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
