Re: Odd behavior observed
От | Marc Evans |
---|---|
Тема | Re: Odd behavior observed |
Дата | |
Msg-id | 20060919135407.L27583@me.softwarehackery.com обсуждение исходный текст |
Ответ на | Re: Odd behavior observed (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Odd behavior observed
|
Список | pgsql-general |
On Tue, 19 Sep 2006, Tom Lane wrote: > Marc Evans <Marc@SoftwareHackery.Com> writes: >> On Tue, 19 Sep 2006, Tom Lane wrote: >>> Hmph. You got any ON INSERT triggers or rules on that table? I can't >>> think of anything else that would interfere with data getting stored. > >> No INSERT triggers. I do have a BEFORE DELETE trigger, and a pile of >> FOREIGN KEY items (which work kinda like an INSERT trigger). > > Hard to see how those could be related --- but it's even harder to > credit that the INSERT would get past the parser with an explicit > reference to the new column and then not store it. I think maybe > something is applying an UPDATE to the row and losing the new value > at that point. Are any of the FKs non-default actions (ON ... SET NULL > or some such that would try to alter data instead of just erroring)? > Also, can you check the cmin field of that row and see if it's greater > than zero? It is zero for the inserted row. Other rows often have a value of 11. The complete FK and TRIGGER list is shown here: Foreign-key constraints: "audit_logs_audit_format_id_fkey" FOREIGN KEY (audit_format_id) REFERENCES audit_formats(id) ON DELETE RESTRICT "audit_logs_audit_log_type_id_fkey" FOREIGN KEY (audit_log_type_id) REFERENCES audit_log_types(id) ON DELETE RESTRICT "audit_logs_audit_log_type_id_fkey1" FOREIGN KEY (audit_log_type_id) REFERENCES audit_log_types(id) ON DELETE RESTRICT "audit_logs_customer_id_fkey" FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE RESTRICT "audit_logs_customer_region_id_fkey" FOREIGN KEY (customer_region_id) REFERENCES customer_regions(id) ON DELETE RESTRICT "audit_logs_sdp_id_fkey" FOREIGN KEY (sdp_id) REFERENCES sdps(id) ON DELETE RESTRICT Triggers: audit_log_delete_trigger BEFORE DELETE ON audit_logs FOR EACH ROW EXECUTE PROCEDURE audit_log_delete_restrict() Any suggested tricks for seeing additional debug information or even roaming through gdb, to try to figure this out? Thanks again - Marc
В списке pgsql-general по дате отправления: