| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: NOWAIT doesn't work |
| Date: | 2012-10-31 16:49:41 |
| Message-ID: | 509156A5.4090900@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Now, is this the right behavior? I'm not sure. But I know for certain
> that making it behave as you expect is very tricky. The table lock is
> grabbed during parse analysis; we'd have to postpone grabbing the lock
> until after we have had the chance to notice that there's a FOR UPDATE
> clause for the table with a NOWAIT option attached.
I think our present behavior violates POLS. Users would logically
expect NOWAIT to work for all types of locks. If we get LOCK TIMEOUT
working in 9.3, this will apply there as well.
No question that changing that would be a new feature, though.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2012-10-31 16:51:56 | Re: Proposal for Allow postgresql.conf values to be changed via SQL |
| Previous Message | Alvaro Herrera | 2012-10-31 14:35:32 | Re: [COMMITTERS] pgsql: Fix erroneous choices of segNo variables |