Good Day,

I recently posted a message here (
http://archives.postgresql.org/pgsql...2/msg00340.php) that the
trigger does not work as it should from time to time. Now the trigger works
on C, before It was on TCL and it had the same problem.
As the trigger works all right in 99.999 % cases (or even more) then we can
make a conclusion that the trigger is written all right. And it was written
in complete accordance with the documentation that is possible to find.
I suggest to write down in documentation for PostgreSQL, that during big
loads triggers can fail in some cases.

Nik

Nikolay Grebnev wrote:
> Good Day,
>
> I recently posted a message here
> (http://archives.postgresql.org/pgsql...2/msg00340.php)
> that the trigger does not work as it should from time to time. Now the
> trigger works on C, before It was on TCL and it had the same problem.
> As the trigger works all right in 99.999 % cases (or even more) then
> we can make a conclusion that the trigger is written all right. And it
> was written in complete accordance with the documentation that is
> possible to find.
> I suggest to write down in documentation for PostgreSQL, that during
> big loads triggers can fail in some cases.
>
>

I think you need to provide a reproducable, self-contained test case, if
possible.

Your previous mail said:

> In php where the queries are formed we see that the query is sent for
> execution and executed ant the base was modified, but the trigger
> seems just to skip it (does not work with the query).

It would be far better to check that the statement has executed in the
log, after turning on log_statement or log_min_duration_statement.

Does it fail in inserts, updates, deletes, or all three?

What platform are you using?

And why are you compiling with -O3?

cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq