Re: Trigger is not working for Inserts from the application

Dear Tom,

Thanks for your detailed reply.

(1) Application is connecting to the same database.
(2) Application is inserting to the same table without much luck with the
trigger.
(3) Application is issuing the right insert command.
(4) I am not able to check this, is there any way I can check this?

I have enabled the logging of all the statements in the conf file and can
see the logs for connection, statements. I have raised the LOG and I can
see the logs in the file without any errors.

But I do not know how to check whether the application is subject to
different ALTER USER .... SET parameters. Could you please give me some
reference to which I can refer for this type of error checking or any other
tips to solve this issue. I have been looking into this since morning
without any positive outcome :(

Thanks once again.

regards
Kiran

On Sat, Sep 10, 2016 at 5:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
> > On 09/10/2016 03:59 AM, Kiran wrote:
> >> What could be the problem ? Why trigger is not working if I insert from
> the
> >> application ? Am I doing anything wrong ?
>
> > If you have not, turn on log_statement:
> > https://www.postgresql.org/docs/9.5/static/runtime-
> config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT
> > Then check your log to see what the application is sending to the
> database.
>
> At a slightly higher level: everything you've shown us looks fine,
> therefore the problem is in something you didn't show us. I've seen
> people have problems like this for all sorts of reasons, eg
>
> 1. Application isn't connecting to the same database as your manual
> sessions. Maybe not even the same server.
>
> 2. Application is using a different search_path setting and therefore
> touching a different table (same name but other schema).
>
> 3. Application isn't issuing the command you think it is, or is failing
> to commit it.
>
> 4. Trigger is firing as expected but something else is overriding its
> change to the data.
>
> Adrian's suggestion of watching log_statement output would help debug
> some of these cases; possibly log_connections would help with others.
> I'd also suggest checking to see if the application is subject to
> different ALTER USER ... SET parameters than your manual session.
> Lastly, RAISE NOTICE is a tried-and-true method of checking whether
> a trigger is firing, but it's not too helpful for debugging queries
> from applications because they invariably drop notices on the floor.
> I'd try RAISE LOG instead, and again watch the server log to see what
> the application is really doing.
>
> regards, tom lane
>