Odd on-update inconsistency
I'm having trouble understanding something I saw in my data from
yesterday involving an inconsistency between values in a table and its
associated rule-updated log table.
For application debugging purposes (effectiveness of web double-submit
suppression) we have a rule that creates an entry in a log table
whenever the table we are watching is updated:
Rule:
foo_update_rule AS ON UPDATE TO foo DO
INSERT INTO foo_updatelog (old_f1, new_f1, old_f2, new_f2...)
VALUES (old.f1, new.f1, old.f2, new.f2...)
Where foo is:
Column | Type | Modifiers
----------+-----------------------------+---------------
r1 | character varying(30) |
r2 | character varying(30) |
...
And foo_updatelog is:
Column | Type | Modifiers
-----------+-----------------------------+---------------
updatetime | timestamp without time zone | default now()
old_r1 | character varying(30) |
new_r1 | character varying(30) |
...
Normally this works well to give us the info we need, but this morning I
found my table showing f1 equal to 4 and my most recent log entries
showing:
updatetime | old_f1 | new_f1
---------------------------+--------+--------
2008-11-25 17:33:45.537564 | 2 | 3
2008-11-25 17:33:45.539737 | 2 | 3
(The field f1 is a counter - the update query casts the varchar(30) to
int, adds one, and casts the result back to varchar(30) due to an
unfortunate current requirement on the application side.)
I was able to verify that this is a legitimately trapped double-submit
but I don't understand why the update log is showing a count of 2->3
twice instead of 2->3 then 3->4 like it typically would.
This database is still in 7.4.x land (I know, we're working on it) so if
it is related to a known issue I didn't find in subsequent release
notes, my apologies. I didn't find anything in the logs that would
explain it.
Any ideas?
Cheers,
Steve
Steve Crawford wrote:
I'm having trouble understanding something I saw in my data from
yesterday involving an inconsistency between values in a table and its
associated rule-updated log table.For application debugging purposes (effectiveness of web double-submit
suppression) we have a rule that creates an entry in a log table
whenever the table we are watching is updated:
Ah, I think you'll find you don't. You have a rule that looks at first
glance like it *should* add an entry to your log table.
Rules rewrite the query like a macro would and OLD and NEW don't refer
to a row but to the entire set of rows. The most common problems you'll
see are related to:
1. nextval() / currval() not behaving like you'd think.
2. in particular with multiple-row updates or inserts
See the mailing list archives for plenty of discussion, and I think the
current manuals have a better description of rules than there used to be.
For inserting to a log table you'll want a trigger.
--
Richard Huxton
Archonet Ltd
Richard Huxton <dev@archonet.com> writes:
Steve Crawford wrote:
I'm having trouble understanding something I saw in my data from
yesterday involving an inconsistency between values in a table and its
associated rule-updated log table.For application debugging purposes (effectiveness of web double-submit
suppression) we have a rule that creates an entry in a log table
whenever the table we are watching is updated:
Ah, I think you'll find you don't. You have a rule that looks at first
glance like it *should* add an entry to your log table.
We'd have to see the original query (the one the rule acted on) to be
sure, but I suspect Richard's diagnosis is correct.
For inserting to a log table you'll want a trigger.
+1 ... triggers are way less likely to do strange things.
regards, tom lane
Richard Huxton wrote:
Steve Crawford wrote:
I'm having trouble understanding something I saw in my data from
yesterday involving an inconsistency between values in a table and its
associated rule-updated log table.For application debugging purposes (effectiveness of web double-submit
suppression) we have a rule that creates an entry in a log table
whenever the table we are watching is updated:Ah, I think you'll find you don't. You have a rule that looks at first
glance like it *should* add an entry to your log table.Rules rewrite the query like a macro would and OLD and NEW don't refer
to a row but to the entire set of rows. The most common problems you'll
see are related to:
1. nextval() / currval() not behaving like you'd think.
2. in particular with multiple-row updates or insertsSee the mailing list archives for plenty of discussion, and I think the
current manuals have a better description of rules than there used to be.For inserting to a log table you'll want a trigger.
Hmmm. I was aware of certain issues with rules but in this case we have
no sequences/nextval()/currval() issues and, except for period-start
resets of certain columns, the normal update query only operates on a
single row (increment count for a given location) - and I reverified
that the key column really is unique.
It's not a big problem (this project ends in a month anyway). I just
want to increase my understanding to avoid future foot-gun potential as
I hadn't seen how our current setup would cause this type of issue. I
guess if it's critical that it works, I'll just write a trigger but
rules are quicker and easier.
Cheers,
Steve