From: | Brilliantov Kirill Vladimirovich <brilliantov(at)byterg(dot)ru> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: NEW in after insert trugger contained incorrect data |
Date: | 2014-11-17 09:04:17 |
Message-ID: | 5469BA11.40507@byterg.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jim Nasby wrote on 11/15/2014 07:57 AM:
>
> Something else to consider: using FOUND to decide whether to INSERT vs
> UPDATE is a race condition: you can do the SELECT, someone else can then
> insert or delete, and then you attempt to do the wrong thing.
>
> To handle this correctly, you need an appropriate UNIQUE constraint or
> primary key, and to follow the pattern in table 40-2 at
> http://www.postgresql.org/docs/9.3/interactive/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING
>
>
> If you don't, and you have concurrent activity you can end up losing
> data (and in the case of a DELETE after your SELECT, the data loss will
> be completely silent).
Hello, Jim!
Table trassa.cpu_load_stat have field id, it is a primary key.
I rewrite trigger with using loop, unfortunately thi not solve problem.
--
Best regards,
Brilliantov Kirill Vladimirovich
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitriy Igrishin | 2014-11-17 09:24:58 | Re: documentation for lo_* functions |
Previous Message | Pawel Veselov | 2014-11-17 08:55:08 | documentation for lo_* functions |