Skip site navigation (1) Skip section navigation (2)

Re: Concurrency

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kris Kiger <kris(at)musicrebellion(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Concurrency
Date: 2005-05-09 21:38:35
Message-ID: 1115674715.3830.78.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
On Mon, 2005-05-09 at 15:18 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > 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?
> > The lock queue is served in FIFO sequence.
> ... usually.  We will promote later arrivals in front of older ones if
> the alternative would be a deadlock (eg, the later one already holds
> some lock that would block the earlier one).

Thats part of deadlock detection? I had thought we just blew one away...


Best Regards, Simon Riggs

In response to


pgsql-admin by date

Next:From: Tom LaneDate: 2005-05-09 21:46:29
Subject: Re: Concurrency
Previous:From: Scott MarloweDate: 2005-05-09 19:48:12
Subject: Re: conversion security update may have slowed our system?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group