Search Postgresql Archives

Re: Trying to understand odd trigger behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 15, 2018 at 08:54:52 +0200,
 Laurenz Albe <laurenz.albe@xxxxxxxxxxx> wrote:
Bruno Wolff III wrote:
I think I know what is happening, but I wanted to see if my understanding
is correct.

I have a perl after insert trigger for a table with a non-null column element
and I am getting an occasional error when the trigger executes for
printing a null value which is $TD->{new}{element}. However, I do the
insert with an on conflict that converts it into an update. And I have
a before update trigger that blocks changing the record, but returns null
if the old and new records are the same.

My theory is that the insert trigger is firing even though the action
got changed to an update and that because the update trigger cancelled
the update, there is no new record. So I should just test for $TD->{new}
being doing before doing stuff.

Does that sound correct?

Absolutely, but it should be easy to run a few tests with only a single row
insert that confirms your theory.

It looks like something else is going on. I tried checking if $_TD->{new}{element} was defined and print some extra information if it wasn't to the local syslog service instead of to the remote elastic server and I was still seeing the issue occasionally without getting the extra info. Also reinserting duplicate data doesn't seem to be a reliable way to reproduce the problem. I didn't see it at all doing it by hand to a small number of records. I only see this on the trigger that sends data to the elastic server and not the one that sends it to the local syslog server. The if the issue is data dependent it would always hit the elastic server trigger first. So that doesn't rule out both triggers from having the same issue, but does suggest that I may want to look at stuff specific to the elastic trigger with extra scrutiny.

I probably need to narrow things down myself as looking at the whole system is going to be too much effort when this might be user error and not a bug. And it isn't self contained as it is part of a system that pulls log data from a third party. That would make it hard for someone else to test.




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux