| From: | Hannu Krosing <hannu(at)tm(dot)ee> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Weird locking situation |
| Date: | 2003-10-02 14:47:40 |
| Message-ID: | 1065106060.2563.60.camel@fuji.krosing.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane kirjutas N, 02.10.2003 kell 17:30:
> Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
> > What is going on here? Surely getting a FOR UPDATE row lock should
> > prevent another process getting an update lock?
> The behavior you describe would certainly be a bug, but you'll have to
> show a reproducible example to convince me it wasn't pilot error. One
> idea that springs to mind is that maybe additional rows with id=1 were
> inserted (by some other transaction) between the SELECT FOR UPDATE and
> the UPDATE?
Perhaps he was looking for "key locking", so thet "select ... where
key=1 for update" would also prevent inserts where key=1 ?
------------
Hannu
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2003-10-02 15:21:46 | [Fwd: [Python-Dev] HP Test Drive systems] |
| Previous Message | Tom Lane | 2003-10-02 14:30:58 | Re: Weird locking situation |