| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Patrick Earl <patearl(at)patearl(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Select For Update and Left Outer Join |
| Date: | 2011-05-01 22:05:20 |
| Message-ID: | 26133.1304287520@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Patrick Earl <patearl(at)patearl(dot)net> writes:
> The query to get all the pets is as follows:
> select * from Pet
> left join Dog on Dog.Id = Pet.Id
> left join Cat on Cat.Id = Pet.Id
> Now suppose you want to lock to ensure that your Cat is not updated
> concurrently. You add FOR UPDATE, but then PostgreSQL gets upset and
> complains that locking on the nullable side of an outer join is not
> allowed.
Quite. What would it mean to lock the absence of a row?
> From our data model, we know that for every single Pet, there can
> never be a Dog or Cat that spontaneously appears, so locking in this
> case is totally safe.
You might know that, but you didn't explain how you know that or how
the database could be expected to know it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-05-01 22:30:34 | Re: strange view performance |
| Previous Message | Kevin Grittner | 2011-05-01 20:38:57 | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |