| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Bruno Wolff III <bruno(at)wolff(dot)to> | 
| Cc: | "Karl O(dot) Pinc" <kop(at)meme(dot)com>, "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, pgsql-general(at)postgresql(dot)org | 
| Subject: | Re: Moving from MySQL to PGSQL....some questions (multilevel | 
| Date: | 2004-03-04 15:50:50 | 
| Message-ID: | 26140.1078415450@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> This won't always work since SELECT FOR UPDATE only locks tuples
> visible to the current transaction. It won't keep another transaction
> from inserting new tuples that would meet the critera. I think the
> current general solution is to lock the table.
If I understood the requirements correctly, it might be sufficient to
put a unique index on (id1,id2).  If two transactions simultaneously try
to insert for the same id1, one would get a duplicate-index-entry
failure, and it would have to retry.  The advantage is you take no
table-wide lock.  So if the normal usage pattern involves lots of
concurrent inserts for different id1 values, you'd come out ahead.
Whether that applies, or is worth the hassle of a retry loop in the
application, I can't tell from the info we've been given.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hervé Piedvache | 2004-03-04 15:53:32 | Tips for public hosting ? | 
| Previous Message | Josué Maldonado | 2004-03-04 15:43:36 | Enable/Disable triggers |