From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hard problem with concurrency |
Date: | 2003-02-17 03:04:53 |
Message-ID: | 01af01c2d631$580a5950$6500a8c0@fhp.internal |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Do the update, then try to insert if the update found nothing, and put
> a retry loop around the whole transaction in case you fail because of
> concurrent inserts.
>
> Realistically you will need a retry loop in all but the most trivial
> cases anyway --- certainly so if you want to use serializable
> transaction mode. So I don't think this solution is unworkably complex.
I guess that will work, but it will not prevent our log from being spammed
up with error messages. Also, this is a somewhat simplified case. Some
transactions, such as our login transaction have rather large numbers of
operations in them and we don't want to have to rollback the whole thing.
I guess we'll have to live with it.
REPLACE INTO anyone? ;)
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Brown | 2003-02-17 03:33:24 | Re: location of the configuration files |
Previous Message | Tom Lane | 2003-02-17 02:58:54 | Re: Hard problem with concurrency |