| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Kris Kiger <kris(at)musicrebellion(dot)com> |
| Cc: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: Concurrency |
| Date: | 2005-05-09 18:58:43 |
| Message-ID: | 1115665123.3830.38.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Mon, 2005-05-09 at 12:21 -0500, Kris Kiger wrote:
> Quick question. I lock a table, call it table X, and then issue two
> updates on that table. The two updates are left waiting. I then unlock
> the table. The two updates go through. My question is, is there a
> predictable way to determine which query will be executed first? Thanks
> in advance
The lock queue is served in FIFO sequence. It is predictable, but if you
don't know which order they were submitted in it might be hard to
determine what that predictable order is, if they were submitted almost
at the same time.
...but you shouldn't use locking as a queuing mechanism.
Best Regards, Simon Riggs
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-05-09 19:10:07 | Re: conversion security update may have slowed our system? |
| Previous Message | Simon Riggs | 2005-05-09 18:55:08 | Re: conversion security update may have slowed our system? |