| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Thomas Munro <munro(at)ip9(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: SKIP LOCKED DATA (work in progress) |
| Date: | 2014-08-04 16:02:44 |
| Message-ID: | 20140804160244.GH5475@eldon.alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley wrote:
> The only notes I can think to leave for the commiter would be around the
> precedence order of the lock policy, especially around a query such as:
>
> SELECT * FROM (SELECT * FROM a FOR UPDATE SKIP LOCKED) a FOR UPDATE; --
> skip locked wins
>
> Of course the current behaviour is that NOWAIT wins over the standard FOR
> UPDATE, but with NOWAIT, there's only a chance of an error, there's no
> chance of giving incorrect results.
Another option is to throw an error at parse analysis time if there is a
conflict in the specified locking policies, as in the above case. Are
there cases in which it would make sense to have one clause trump the
other? It seems reasonable to have NOWAIT trump regular FOR UPDATE (as
it already does), since, as you say, there's chance of error being
thrown at runtime, but not of incorrect result.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Claudio Freire | 2014-08-04 18:30:21 | Re: Proposal: Incremental Backup |
| Previous Message | Bruce Momjian | 2014-08-04 15:47:24 | pg_upgrade autovacuum_multixact_freeze_max_age fix |