From: | Kris Kiger <kris(at)musicrebellion(dot)com> |
---|---|
To: | "Pgsql-Admin (E-mail)" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Functions and transactions |
Date: | 2005-03-11 16:48:46 |
Message-ID: | 4231CBEE.60109@musicrebellion.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers pgsql-patches |
Interesting. That makes sense, though. So, is there a good way to lock
a set of rows using SELECT FOR UPDATE in plpgsql? I assume using
PERFORM would yield the same problem, because it immediately discards
the results.
Thanks!
Kris
Tom Lane wrote:
>Kris Kiger <kris(at)musicrebellion(dot)com> writes:
>
>
>>In your second paragraph, I think that you are saying that SELECT FOR
>>UPDATE only locks one row, even though the select itself may return
>>many. Am I mis-interpreting you?
>>
>>
>
>No, I'm saying that plpgsql's SELECT INTO operation only reads one row.
>The fact that the SELECT might have found more rows if allowed to run
>to completion doesn't enter into it. If the first row read doesn't have
>active = true then it won't conflict against concurrent UPDATEs, because
>you are carefully not UPDATEing rows with active = false. It's the
>combination of those two things that creates the hazard.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2005-03-11 16:49:01 | Re: [HACKERS] PostgreSQL pam ldap document |
Previous Message | Michael Fuhr | 2005-03-11 16:46:41 | Re: Too frequent warnings for wraparound failure |
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2005-03-11 16:49:01 | Re: [HACKERS] PostgreSQL pam ldap document |
Previous Message | Michael Fuhr | 2005-03-11 16:46:41 | Re: Too frequent warnings for wraparound failure |
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql | 2005-03-11 17:02:29 | Re: [pgsql-hackers-win32] snprintf causes regression |
Previous Message | Bruce Momjian | 2005-03-11 16:21:23 | Re: [pgsql-hackers-win32] snprintf causes regression tests |