From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | "David(dot)I(dot)Noel(at)gmail(dot)com" <David(dot)I(dot)Noel(at)gmail(dot)com>, Ralf Schuchardt <rasc(at)gmx(dot)de> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Small PosgreSQL locking function request - with bounty |
Date: | 2013-09-14 15:29:46 |
Message-ID: | 1379172586.30975.YahooMailNeo@web162901.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
David Noel <david(dot)i(dot)noel(at)gmail(dot)com> wrote:
> I've read through the documentation, found a few examples using
> "for update" syntax, and it looks like you're right. Would
> transaction level SERIALIZABLE also work? It does seem messier
> though, having to handle errors thrown due to concurrent
> transactions.
The SERIALIZABLE transaction isolation level, as implemented in
PostgreSQL, would provide correct behavior; but is not a very
efficient way to handling access to the ends of a queue.
Regardless of the isolation level you use for other things, you
probably want blocking around access to the ends of the queue -- or
at least to the part where you pull an item from the queue for
processing. The tricky part is likely to be making sure that if
something is pulled from the queue it gets processed or gets put
back onto the queue. Without careful planning you might risk
either losing items or blocking not just for pulling off the queue,
but all the way through processing.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-09-14 15:51:02 | Re: Postgres 9.2.4 "Double Precision" Precision |
Previous Message | CS DBA | 2013-09-14 15:26:31 | Re: How to switch file systems with least downtime? |