[BUGS] BUG #4303: insufficient privileges
The following bug has been logged online: Bug reference: 4303 Logged by: Alexandre Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Windows xp Description:insufficient privileges Details: Hi, I have been getting the following error everytime I tried to install PostgreSQL: Service 'PostgreSQL Database Server 8.2' (pgsql-8.2) failed to start. Verify that you have sufficient privileges to start system services I am loged in as an administrator. I searched forums etc... but found no clear answers... Im really desperate ! Can't solve this stupid problem... Can you help me ? Thank you Alexandre -- 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 #5859: XML result in line and column
The following bug has been logged online:
Bug reference: 5859
Logged by: Alexandre
Email address: ultr...@gmail.com
PostgreSQL version: 8.4.7
Operating system: Windows 7
Description:XML result in line and column
Details:
The name of the xml tag is not being updated, becoming the first name
registry for all. Here is example:
Create table AUDITORIA_ANTERIOR
(
SEQUENCIA Serial NOT NULL,
SEQUENCIA_AUDITORIA Integer NOT NULL,
REGISTRO Text NOT NULL,
primary key (SEQUENCIA,SEQUENCIA_AUDITORIA)
);
insert into auditoria_anterior (sequencia_auditoria, registro)
values (1, '
123456789011FJOAO DA
SILVA ')
SELECT * FROM
xpath_table('sequencia',
'registro',
'auditoria_anterior',
'name(/ROOT/CLIENTES/*)|/ROOT/CLIENTES/*',
'sequencia = 1')
AS t(sequencia integer, coluna text, valor text)
--Incorrect result---
sequencia colunavalor
integer text text
--
1 CGC_CPF_CLIENTE 12345678901
1 CGC_CPF_CLIENTE 1
1 CGC_CPF_CLIENTE F
1 CGC_CPF_CLIENTE JOAO DA SILVA
--Result that would be right to be presented--
sequencia colunavalor
integer text text
--
1 CGC_CPF_CLIENTE 12345678901
1 TIPO 1
1 PESSOAF
1 NOME JOAO DA SILVA
--
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 #4320: Describe table on 8.2.9 server fail
The following bug has been logged online: Bug reference: 4320 Logged by: Alexandre Payment Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.3 Operating system: Ubuntu Linux 8.04 Description:Describe table on 8.2.9 server fail Details: Connected to a 8.2.9 non-local server with psql version 8.3.3 and entering the following command (describe table t_ann): \d t_ann this error occur: ERROR: column t.tgconstraint does not exist LINE 3: WHERE t.tgrelid = '16627' AND t.tgconstraint = 0 When connect with psql version 8.2.9 the describe command work perfectly. -- 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 #4320: Describe table on 8.2.9 server fail
2008/7/22 toruvinn <[EMAIL PROTECTED]>: > > Dnia 22-07-2008 o 14:36:22 Alexandre Payment <[EMAIL PROTECTED]> napisał(a): > I'm afraid that's what the warning: >WARNING: You are connected to a server with major version 8.2, >but your psql client is major version 8.3. Some backslash commands, >such as \d, might not work properly. > are for. > > -- > ru Sorry, I didn't notice it. But warning or not, it's not working. I was just hoping that basic commands like \d will be backward compatible. Maybe I'm just too optimist. -- Alexandre Payment http://www.anncse.com -- 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 #4322: Problems with field not updatable
The following bug has been logged online:
Bug reference: 4322
Logged by: Alexandre Caneo
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.6
Operating system: WIN XP
Description:Problems with field not updatable
Details:
I'm using Win XP SP2, VB6 and PostgreSql 8.2.6.
When I select the datas with this instruction
"select a.x from a,b where a.z = b.z order by 1"
the program run very well and I can insert, update and delete rows. But,
when I select any column from table b an error occurs when I try to modify
the column value from textbox for an example.
"Binding Collection Error. field not updatable".
String connection
ls_StrConn = "PROVIDER=MSDASQL.1; DRIVER={PostgreSQL UNICODE};
DATABASE=" & ls_Conexao & "; SERVER=" & ls_Host & "; PORT=" & ls_Servico &
"; UID=" & ls_login & "; PWD=" & ls_Senha & "; ByteaAsLongVarBinary=1;"
Recordset's properties
mo_Record.CursorType = adOpenDynamic
mo_Record.LockType = adLockOptimistic
mo_Record.Open mo_Command
One more thing.
I don't need update the table's b column, just show them.
Any suggestions would be appreciated.
Best regards.
Alexandre.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
RES: [BUGS] BUG #4322: Problems with field not updatable
Magnus,
I've tried open cursor with adOpenStatic or adOpenForwardOnly, but it didn't
work.
Do you have others suggestions?
Tks.
Alexandre.
-Mensagem original-
De: Magnus Hagander [mailto:[EMAIL PROTECTED]
Enviada em: segunda-feira, 28 de julho de 2008 08:34
Para: Alexandre Caneo
Cc: pgsql-bugs@postgresql.org
Assunto: Re: [BUGS] BUG #4322: Problems with field not updatable
Alexandre Caneo wrote:
> The following bug has been logged online:
>
> Bug reference: 4322
> Logged by: Alexandre Caneo
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.6
> Operating system: WIN XP
> Description:Problems with field not updatable
> Details:
>
> I'm using Win XP SP2, VB6 and PostgreSql 8.2.6.
>
> When I select the datas with this instruction
> "select a.x from a,b where a.z = b.z order by 1"
> the program run very well and I can insert, update and delete rows. But,
> when I select any column from table b an error occurs when I try to modify
> the column value from textbox for an example.
> "Binding Collection Error. field not updatable".
>
> String connection
> ls_StrConn = "PROVIDER=MSDASQL.1; DRIVER={PostgreSQL UNICODE};
> DATABASE=" & ls_Conexao & "; SERVER=" & ls_Host & "; PORT=" & ls_Servico &
> "; UID=" & ls_login & "; PWD=" & ls_Senha & "; ByteaAsLongVarBinary=1;"
>
> Recordset's properties
> mo_Record.CursorType = adOpenDynamic
> mo_Record.LockType = adLockOptimistic
>
> mo_Record.Open mo_Command
>
> One more thing.
> I don't need update the table's b column, just show them.
If you don't need updating, you should open your cursor as either
adOpenStatic or adOpenForwardOnly. Using adOpenDynamic explicitly
requests the ability to do updates/inserts/deletes through the cursor.
//Magnus
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.441 / Virus Database: 270.5.6/1523 - Release Date: 25/7/2008 00:00
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.441 / Virus Database: 270.5.6/1523 - Release Date: 25/7/2008 00:00
--
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 #5779: Large INSERT transaction with FOREIGN KEY constraints exhausts available RAM
The following bug has been logged online: Bug reference: 5779 Logged by: Michel Alexandre Salim Email address: michel.sa...@cs.fau.de PostgreSQL version: 9.0.1 Operating system: Ubuntu 10.04 Description:Large INSERT transaction with FOREIGN KEY constraints exhausts available RAM Details: Explanation: I have a table with close to a billion rows that was initially imported in csv form; as such, a lot of the columns were not normalized. For speed reasons, I created one temporary table for each column that needs to be normalized, and then did an INSERT with JOINs to populate the new table with the normalized data. If foreign key constraints are enabled, this runs out of memory (the machine has 4GB RAM + 6 GB swap and nothing else is running that requires much RAM; 4 GB of the swap was actually added to try and debug this). With vm.overcommit_memory set to the default 0 the OOM killer consistently kills the process handling the query; with it set to the recommended 2 postgresql itself aborts the query when it cannot allocate more RAM. I tried changing the fkey constraints to DEFERRABLE hoping that that would consume less RAM, but the same result occurs. Why should the memory usage pattern be different when integrity checks are done as part of the transaction (even when pushed back to the end), and in a separate transaction? The dataset I'm using is the Eclipse UDC dataset for 2009 -- http://archive.eclipse.org/technology/phoenix/usagedata/ -- and the problem is independently described at this other site, with a simpler query: http://www.jory.info/serendipity/archives/30-PostgreSQL-Out-of-Memory-with-l arge-INSERT.html My own invocations were CREATE TABLE udc (id INTEGER PRIMARY KEY, eclipse_id INTEGER NOT NULL, ac│ ion_type_id INTEGER NOT NULL, target_type_id INTEGER, source_id INTEGER NOT NUL│ , version_id INTEGER NOT NULL, target_id INTEGER, tstamp TIMESTAMPTZ NOT NULL,│ FOREIGN KEY (action_type_id) REFERENCES actions (id) DEFERRABLE, FOREIGN KEY (t│ rget_type_id) REFERENCES class_types (id) DEFERRABLE, FOREIGN KEY (source_id) R│ FERENCES classes (id) DEFERRABLE, FOREIGN KEY (version_id) REFERENCES versions │ id) DEFERRABLE , FOREIGN KEY (target_id) REFERENCES classes (id) DEFERRABLE); │ NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "udc_pkey" for t│ ble "udc" │ CREATE TABLE │ udc=# INSERT INTO udc (id, eclipse_id, action_type_id, target_type_id, source_i│ , version_id, target_id, tstamp) SELECT old_udc.id, old_udc.eclipse_id, old_udc│ action_type, newttype.type_id, old_udc.source, newv.v_id, newt.t, old_udc.tstam│ FROM old_udc NATURAL JOIN newttype NATURAL JOIN newv NATURAL JOIN newt; │ ERROR: out of memory │ DETAIL: Failed on request of size 1048576. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
