Thread: Crash and sending report !
Hi, When ever there's a crash (it's about every other time ... when I close PG Admin ... so no big deal ;-) !) is it worth mesending the report to Microsoft ? Does it get to the PG Admin people in the end ? Cheers, L@u The Computing Froggy ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
> ------- Original Message ------- > From: Laurent ROCHE <laurent_roche@yahoo.com> > To: pgadmin-support@postgresql.org > Sent: 1/18/07, 7:21:35 PM > Subject: [pgadmin-support] Crash and sending report ! > > Hi, > > When ever there's a crash (it's about every other time ... when I close PG Admin ... so no big deal ;-) !) is it worthme sending the report to Microsoft ? > Does it get to the PG Admin people in the end ? > LOL! No, we'll never see those! What crashes though? That should never happen :-( RegardS, Dave
2007/1/18, Dave Page <dpage@postgresql.org>:
>
>
> > ------- Original Message -------
> > From: Laurent ROCHE <laurent_roche@yahoo.com>
> > To: pgadmin-support@postgresql.org
> > Sent: 1/18/07, 7:21:35 PM
> > Subject: [pgadmin-support] Crash and sending report !
> >
> > Hi,
> >
> > When ever there's a crash (it's about every other time ... when I close PG Admin ... so no big deal ;-) !) is it
worthme sending the report to Microsoft ?
> > Does it get to the PG Admin people in the end ?
> >
>
> LOL! No, we'll never see those!
>
> What crashes though? That should never happen :-(
I can always reproduce a crash:
1) Right click a table
2) Select View Data -> View top 100 rows
3) Click the row number to select it
4) Click the delete icon (Trash)
5) Click Yes on the confirmation dialog.
6) Certain crash
The row is not deleted. I can delete it with a delete command in psql.
Is there some log I could send?
Fedora Core 5 i386, PgAdmin 1.6.2
Table definition:
CREATE TABLE vendedor
( nome_usuario character varying(20) NOT NULL, nome_completo character varying(100) NOT NULL, bairro_id integer NOT
NULL,email character varying(150) NOT NULL, cpf character(11) NOT NULL, id serial NOT NULL, ip inet, data timestamp
withtime zone DEFAULT now(), senha bytea, CONSTRAINT vendedor_pkey PRIMARY KEY (cpf), CONSTRAINT
vendedor_bairro_id_fkeyFOREIGN KEY (bairro_id) REFERENCES bairro (id) MATCH SIMPLE ON UPDATE NO ACTION ON
DELETENO ACTION, CONSTRAINT vendedor_id_key UNIQUE (id), CONSTRAINT vendedor_cpf_check CHECK (cpf ~ '[0-9]{11}'::text
AND
valida_cpf(cpf)), CONSTRAINT vendedor_email_check CHECK (email::text ~ '.+?@.+\\..+'::text)
)
WITHOUT OIDS;
ALTER TABLE vendedor OWNER TO cpn;
GRANT ALL ON TABLE vendedor TO cpn;
GRANT SELECT, UPDATE, INSERT ON TABLE vendedor TO car;
-- Index: lower_nome_usuario
-- DROP INDEX lower_nome_usuario;
CREATE UNIQUE INDEX lower_nome_usuario ON vendedor USING btree (lower(nome_usuario::text));
Regards,
--
Clodoaldo Pinto Neto
Clodoaldo wrote: > 2007/1/18, Dave Page <dpage@postgresql.org>: >> >> >> > ------- Original Message ------- >> > From: Laurent ROCHE <laurent_roche@yahoo.com> >> > To: pgadmin-support@postgresql.org >> > Sent: 1/18/07, 7:21:35 PM >> > Subject: [pgadmin-support] Crash and sending report ! >> > >> > Hi, >> > >> > When ever there's a crash (it's about every other time ... when I >> close PG Admin ... so no big deal ;-) !) is it worth me sending the >> report to Microsoft ? >> > Does it get to the PG Admin people in the end ? >> > >> >> LOL! No, we'll never see those! >> >> What crashes though? That should never happen :-( > > I can always reproduce a crash: > > 1) Right click a table > 2) Select View Data -> View top 100 rows > 3) Click the row number to select it > 4) Click the delete icon (Trash) > 5) Click Yes on the confirmation dialog. > 6) Certain crash > > The row is not deleted. I can delete it with a delete command in psql. > Works fine for me with my dummy data - but I did have to remove the foreign key and the call to valida_cpf(cpf) in the cpf check constraint. When you delete in psql, do you see any notices from the backend? Are there any other tables referencing this one that might be preventing the delete (not that that should cause a crash either of course). Regards, Dave.
2007/1/19, Dave Page <dpage@postgresql.org>: > Clodoaldo wrote: > > 2007/1/18, Dave Page <dpage@postgresql.org>: > >> > >> > >> > ------- Original Message ------- > >> > From: Laurent ROCHE <laurent_roche@yahoo.com> > >> > To: pgadmin-support@postgresql.org > >> > Sent: 1/18/07, 7:21:35 PM > >> > Subject: [pgadmin-support] Crash and sending report ! > >> > > >> > Hi, > >> > > >> > When ever there's a crash (it's about every other time ... when I > >> close PG Admin ... so no big deal ;-) !) is it worth me sending the > >> report to Microsoft ? > >> > Does it get to the PG Admin people in the end ? > >> > > >> > >> LOL! No, we'll never see those! > >> > >> What crashes though? That should never happen :-( > > > > I can always reproduce a crash: > > > > 1) Right click a table > > 2) Select View Data -> View top 100 rows > > 3) Click the row number to select it > > 4) Click the delete icon (Trash) > > 5) Click Yes on the confirmation dialog. > > 6) Certain crash > > > > The row is not deleted. I can delete it with a delete command in psql. > > > > Works fine for me with my dummy data - but I did have to remove the > foreign key and the call to valida_cpf(cpf) in the cpf check constraint. > > When you delete in psql, do you see any notices from the backend? No > Are > there any other tables referencing this one that might be preventing the > delete (not that that should cause a crash either of course). Yes, there is a table with a FK referencing this one. But I'm deleting a not referenced row to reproduce the crash. I also tried to delete a row referenced by that other table and it crashs the same. If there is a method to trace the crash just let me know and I will try to use it. Regards, -- Clodoaldo Pinto Neto
Clodoaldo wrote: > If there is a method to trace the crash just let me know and I will > try to use it. You could try setting the log level to debug and reproducing the problem (see the Logging settings on the options dialog. If you can dump and reload your database into a temporary copy, it would be interesting to see if that works as well. Regards Dave.