Re: Really strange foreign key constraint problem blocking delete - Mailing list pgsql-general

From Tim Mickelson
Subject Re: Really strange foreign key constraint problem blocking delete
Date
Msg-id 542F8987.90301@bigfoot.com
Whole thread Raw
In response to Re: Really strange foreign key constraint problem blocking delete  (Vick Khera <vivek@khera.org>)
Responses Re: Really strange foreign key constraint problem blocking delete
Re: Really strange foreign key constraint problem blocking delete
List pgsql-general
But I don't think so, but here are the table defenitions:


CREATE TABLE bulldog.channel_mapping
(
  idchannel integer NOT NULL,
  idaut integer NOT NULL,
  CONSTRAINT channel_mapping_pk PRIMARY KEY (idchannel, idaut),
  CONSTRAINT channel_mapping_idaut_fkey FOREIGN KEY (idaut)
      REFERENCES cubesocialnetwork.tmp_autenticazionesocial
(idautenticazionesocial) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT channel_mapping_idchannel_fkey FOREIGN KEY (idchannel)
      REFERENCES bulldog.social_channel (idchannel) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);
ALTER TABLE bulldog.channel_mapping
  OWNER TO postgres;





-- Table: cubesocialnetwork.tmp_autenticazionesocial

-- DROP TABLE cubesocialnetwork.tmp_autenticazionesocial;

CREATE TABLE cubesocialnetwork.tmp_autenticazionesocial
(
  idautenticazionesocial serial NOT NULL,
  contratto text NOT NULL,
  idlocation numeric NOT NULL,
  textuser text,
  textpassword text,
  datacrea timestamp without time zone NOT NULL DEFAULT now(),
  idsocial numeric NOT NULL,
  location text,
  username text,
  link_foto text,
  valid text,
  link_profilo text,
  tweetmonitored boolean DEFAULT false,
  idutente text,
  tipologia text,
  api_key text,
  api_secret text,
  CONSTRAINT tmp_autenticazionesocial_pkey PRIMARY KEY
(idautenticazionesocial),
  CONSTRAINT tipo_social_fk FOREIGN KEY (idsocial)
      REFERENCES cubesocialnetwork.tipo_social (cd_social) MATCH FULL
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);
ALTER TABLE cubesocialnetwork.tmp_autenticazionesocial
  OWNER TO postgres;

-- Index: cubesocialnetwork.indice_tmp_autenticazione

-- DROP INDEX cubesocialnetwork.indice_tmp_autenticazione;

CREATE INDEX indice_tmp_autenticazione
  ON cubesocialnetwork.tmp_autenticazionesocial
  USING btree
  (textpassword COLLATE pg_catalog."default");

-- Index: cubesocialnetwork.indicetextuser

-- DROP INDEX cubesocialnetwork.indicetextuser;

CREATE INDEX indicetextuser
  ON cubesocialnetwork.tmp_autenticazionesocial
  USING btree
  (textuser COLLATE pg_catalog."default");

-- Index: cubesocialnetwork.indicidentificativosocial

-- DROP INDEX cubesocialnetwork.indicidentificativosocial;

CREATE INDEX indicidentificativosocial
  ON cubesocialnetwork.tmp_autenticazionesocial
  USING btree
  (idsocial);

-- Index: cubesocialnetwork.tmpautenticazione

-- DROP INDEX cubesocialnetwork.tmpautenticazione;

CREATE INDEX tmpautenticazione
  ON cubesocialnetwork.tmp_autenticazionesocial
  USING btree
  (idautenticazionesocial);

-- Index: cubesocialnetwork.tmpautenticazionecontrattoidlocation

-- DROP INDEX cubesocialnetwork.tmpautenticazionecontrattoidlocation;

CREATE INDEX tmpautenticazionecontrattoidlocation
  ON cubesocialnetwork.tmp_autenticazionesocial
  USING btree
  (contratto COLLATE pg_catalog."default", idlocation);

-- Index: cubesocialnetwork.tmpauteticazionesocial

-- DROP INDEX cubesocialnetwork.tmpauteticazionesocial;

CREATE INDEX tmpauteticazionesocial
  ON cubesocialnetwork.tmp_autenticazionesocial
  USING btree
  (username COLLATE pg_catalog."default");


On 03/10/2014 20:38, Vick Khera wrote:
> Using my magick powers of mind reading, I will guess you made circular
> dependencies.
>
> On Fri, Oct 3, 2014 at 12:17 PM, Tim Mickelson
> <tim_mickelson@bigfoot.com> wrote:
>> Even if I try to delete the data entry in the table channel_mapping with
>> idaut 1622, it is not possible to delete from the table
>> tmp_autenticazionesocial with the error below. How is this even possible
>> since there is no channel_mapping with idaut 1622 any more?? I tried
>> this in Java under a transaction, but also in pgAdmin III.
>>
>>
>> ERROR:  update or delete on table "tmp_autenticazionesocial" violates
>> foreign key constraint "channel_mapping_idaut_fkey" on table
>> "channel_mapping"
>> DETAIL:  Key (idautenticazionesocial)=(1622) is still referenced from
>> table "channel_mapping".
>>
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>



pgsql-general by date:

Previous
From: Andy Colson
Date:
Subject: Re: Processor usage/tuning question
Next
From: Adrian Klaver
Date:
Subject: Re: Really strange foreign key constraint problem blocking delete