On Tue, 19 Sep 2006, Tom Lane wrote:

Marc Evans <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to