| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Nikolay Grebnev <nikolaygrebnev(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Trigger problem - conclusion |
| Date: | 2007-12-12 20:45:45 |
| Message-ID: | 47604879.10300@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Nikolay Grebnev wrote:
> Good Day,
>
> I recently posted a message here
> (http://archives.postgresql.org/pgsql-hackers/2007-12/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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gavin Sherry | 2007-12-12 20:46:16 | Re: VLDB Features |
| Previous Message | Joshua D. Drake | 2007-12-12 20:25:56 | Re: Slow PITR restore |