[BUGS]
Me rindo Llevo una semana tratando de instalar postgres y simplemente es demasiado difícil, es más fácil cambiar a otra base de datos
[BUGS] Insert aborted, but Sequence increased
Hi,
While using Postgres, I encountered some unexpected behaviour.
In short:
-
Upon doing a faulty INSERT which left a column with default value
nextval('sequence') unspecified, the INSERT aborted due to an error.
However, a call had been placed to nextval('sequence'), thus
increasing the sequence, while this value never got used.
I certainly didn't expect this.
Detailed report:
Table projectlist looks like:
wwf-projects=# \d projectlist
Table "projectlist"
Column| Type | Modifiers
-+---+
id | integer | not null default
nextval('"projectlist_id_seq"'::text)
dbms_host | character varying(30) | not null
dbms_port | numeric(5,0) | not null
dbms_type | character varying(10) | not null
db_name | character varying(20) | not null
admin_login | character varying(20) | not null
admin_pwd | character varying(20) | not null
Unique keys: projectlist_id_key
We have a SEQUENCE for id:
wwf-projects=# select currval('"projectlist_id_seq"'::text);
currval
-
6
(1 row)
Now if we try to perform a faulty INSERT, the INSERT aborts. However,
the SEQUENCE is increased!:
wwf-projects=# insert into projectlist (dbms_host, dbms_port, dbms_type,
db_name, admin_login, admin_pwd) values ('webadmict.tue.nl','5432',
'hugotest-2', 'test', 'test');
ERROR: ExecAppend: Fail to add null value in not null attribute admin_pwd
wwf-projects=# select currval('"projectlist_id_seq"'::text);
currval
-
7
(1 row)
So 'currval' increased due to an INSERT that was aborted.
(Yes, the insert is definately not in the table).
I'm not sure if one can call this a bug, but it is unexpected behaviour
-- to me, at least.
Regards,
Hugo Jonker.
PS: My apologies about not being on the list, but it was taking longer than
expected to get on.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug #711: Automatic created indexes can in some cases not be referenced to
On Fri, Jul 12, 2002 at 07:19:58AM -0400, [EMAIL PROTECTED] wrote: > Long Description > It looks as if automatic created indexes can in some cases not be referenced to >because long names are truncated. See example SQL statement below. There's a typo in your statement. The sequence name gets truncated to 'whois_block_table_dat_block_seq' instead of 'whois_block_table_date_block_seq', which is the name you're using in the GRANT statement. See the two notices: > NOTICE: CREATE TABLE will create implicit sequence 'whois_block_table_dat_block_seq' for SERIAL column 'whois_block_table_date.block' > NOTICE: identifier "whois_block_table_date_block_seq" will be truncated to "whois_block_table_date_block_se" Hugo. ---(end of broadcast)--- TIP 3: 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 #1872: Failed to create process: 2!
The following bug has been logged online: Bug reference: 1872 Logged by: Hugo Cesar Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1, 8.2 and8.3 Operating system: Win2000 Server and Win2000 Pro Description:Failed to create process: 2! Details: This error appear with the installer when select the language and press the next buttton ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2388: PostsgreSQL fails under isntallation
The following bug has been logged online: Bug reference: 2388 Logged by: Hugo Quisbert Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Windows XP Description:PostsgreSQL fails under isntallation Details: PostgreSQL do fails under installation process. I got an alert saying: "Failed to run initdb: 1!" Besides no logfile is created. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #8152: strange behavior regarding after triggers and inheritance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El 13/05/13 17:06, Tom Lane escribió: > hcu...@exa.unicen.edu.ar writes: >> PostgreSQL version: 8.4.17 > >> After statments triggers on child tables are sometimes executed and >> sometimes are not. As I far as I could see, when the after trigger is >> defined in only one of the tables it may not get executed, wether when it is >> defined in every inherited table it does, but >> which one is undetermined. > > This test case appears to work the way you're expecting in 9.0 and > later. I didn't immediately find a mention of such a change in the > commit logs; perhaps it got fixed as a side-effect of the changes that > moved trigger processing into ModifyTable plan nodes. Anyway, I doubt > we'd consider changing trigger behavior in 8.4.x at this late date. > You should update to a newer release series if this is a problem for you. > > regards, tom lane Thank you Tom, The update to 9.x is already planned, and the workaround I mentioned in the post works for me. regards, Hugo - -- mailto:hcu...@exa.unicen.edu.ar http://www.exa.unicen.edu.ar/~hcurti Firma digital GPG/PGP: http://www.exa.unicen.edu.ar/~hcurti/firma_hcurti.asc Puede hacer una donación indirecta (gratis) de un plato de comida para un niño de la Argentina ahora mismo ingresando a http://www.porloschicos.com/servlet/PorLosChicos?comando=donar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlGRZLEACgkQy9s+D7eSFvn2uwCeL3v4sQpkLgvN3xmHIVYN/2Ic NEcAoOrR+NXMzfarmgKxjDSun2docaC5 =6buB -END PGP SIGNATURE- -- 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 #4055: Using Like in PostgreSQL 8.2.7 and 8.3.1
The following bug has been logged online: Bug reference: 4055 Logged by: Hugo Rafael Lesme Marquez Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.7 and 8.3.1 Operating system: Windows 2003 Server SP2 Description:Using Like in PostgreSQL 8.2.7 and 8.3.1 Details: Using PostgreSQL Database 8.2.7 and 8.3.1 With PostgreSQL 8.2.7 select * from movimientos where idmovimientos like '178' returns 178; "2008-02-16"; 4700.00; 2; 1; "2008-02-22 16:39:09.14"; 2; "maricel"; 2 Ok!!! With PostgreSQL 8.3.1 select * from movimientos where idmovimientos like '178' returns ERROR: operator does not exist: bigint ~~ unknown LINE 1: select * from movimientos where idmovimientos like '178' ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. ** Error ** ERROR: operator does not exist: bigint ~~ unknown SQL state: 42883 Dica: No operator matches the given name and argument type(s). You might need to add explicit type casts. Caracter: 47 What can I do to resolve? Hugo -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
