From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | James Pharaoh <james(at)pharaohsystems(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Transactions and insertion ordering |
Date: | 2004-06-10 10:15:53 |
Message-ID: | 20040610101549.GA10766@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
nextval() should return value in the order they were called, rather
than commit time. I hope you're not relying on the unordered results of
a table scan remaining stable. Tables have no intrinsic "order", only
one inposed by an external sequence.
Hope this helps,
On Thu, Jun 10, 2004 at 09:28:50AM +0100, James Pharaoh wrote:
> Hi,
>
> I'm trying to work out how to make sure things are read from a table in
> a consistent order. The table represents a queue of items and also the
> history of those items.
>
> Even with "serializable" transaction isolation I can begin two
> transactions, insert a record in each, commit the second transaction
> first. This second record is now visible and can be read from the queue.
> But when I commit the first this one appears before the second one. This
> could then be read from the queue second but when I rescan the table to
> view history it looks like it was read first.
>
> Are there any ways to make this work a little more intuitively?
> Basically I guess I want to be able to model a queue effectively.
>
> James
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
From | Date | Subject | |
---|---|---|---|
Next Message | Karsten Hilbert | 2004-06-10 11:51:44 | Re: Postgresql vs. aggregates |
Previous Message | NMB Webmaster | 2004-06-10 09:34:29 | Different runtime on the same query |