| From: | Heiko Wundram <modelnine(at)modelnine(dot)org> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Sporadic query not returning anything..how to diagnose? |
| Date: | 2011-11-29 15:57:28 |
| Message-ID: | 4ED500E8.5060603@modelnine.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Am 29.11.2011 16:46, schrieb Phoenix Kiula:
> About 5% of the times (in situations of high traffic), this is not
> returning a value in my PHP code. Because it's not found, the code
> tries to INSERT a new record and there's a duplicate key error, which
> is in the logs. The traffic to the site is much higher than the number
> of these entries in my log, which means it's only happening
> sometimes--my guess is for 5% of all queries, which is still quite
> significant (about 60,000 a day).
As the two statements aren't atomic (i.e., after the select, how do you
make sure that no other process accessing the DB has a chance to
select/insert, before the [delayed] insert of the primary process gets
executed)? This is a common form of race-condition.
In the spirit of "it's easier to ask forgiveness than permission", just
do the insert and evaluate the result (i.e., whether a record was
actually inserted) to get at the same information and the same effect as
with the two statements you're currently executing.
--
--- Heiko.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | J.V. | 2011-11-29 17:47:27 | Re: stored function data structures - difficulty |
| Previous Message | Phoenix Kiula | 2011-11-29 15:46:48 | Sporadic query not returning anything..how to diagnose? |