From: | Marc Evans <Marc(at)SoftwareHackery(dot)Com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Odd behavior observed |
Date: | 2006-09-19 17:56:47 |
Message-ID: | 20060919135407.L27583@me.softwarehackery.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Tue, 19 Sep 2006, Tom Lane wrote:
> Marc Evans <Marc(at)SoftwareHackery(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-19 17:58:40 | Re: Odd behavior observed |
Previous Message | Tom Lane | 2006-09-19 17:38:07 | Re: Odd behavior observed |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-19 17:58:40 | Re: Odd behavior observed |
Previous Message | Heikki Linnakangas | 2006-09-19 17:55:04 | Re: Getting rid of cmin and cmax |