On Wed, 2006-06-28 at 21:20 +0200, Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 02:48:01PM -0400, Brad Nicholson wrote:
I'm seeing something fairly unintuitive about serializable transactions.
Taking the following test case:
snip
On Thu, Jun 29, 2006 at 01:21:19PM +0100, Simon Riggs wrote:
The issue is the difference between start of transaction and time when
the serializable snapshot is taken. Since BEGIN and other commands may
be issued as separate network requests it makes sense to defer taking
the snapshot until
On Thu, 2006-06-29 at 14:27 +0200, Martijn van Oosterhout wrote:
On Thu, Jun 29, 2006 at 01:21:19PM +0100, Simon Riggs wrote:
The issue is the difference between start of transaction and time when
the serializable snapshot is taken. Since BEGIN and other commands may
be issued as separate
Tom Lane [EMAIL PROTECTED] wrote
Right, the snapshot does not become set until you do a non-utility
command (normally, SELECT/INSERT/UPDATE/DELETE). This is a feature, not
a bug, because it lets the transaction take table locks before its
snapshot becomes set.
Hm, mostly I understand it
Qingqing Zhou [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote
Right, the snapshot does not become set until you do a non-utility
command (normally, SELECT/INSERT/UPDATE/DELETE). This is a feature, not
a bug, because it lets the transaction take table locks before its
snapshot
Tom Lane [EMAIL PROTECTED] wrote
It can, but there are cases where you want the lock to be taken before
the snapshot is set. Otherwise, there could be committed changes in the
database that you can't see in your snapshot. I think there are some
examples in the manual, or check the
On Thu, Jun 29, 2006 at 14:27:30 +0200,
Martijn van Oosterhout kleptog@svana.org wrote:
On Thu, Jun 29, 2006 at 01:21:19PM +0100, Simon Riggs wrote:
The issue is the difference between start of transaction and time when
the serializable snapshot is taken. Since BEGIN and other commands may
I'm seeing something fairly unintuitive about serializable transactions.
Taking the following test case:
CREATE TABLE foo (id integer);
t1 t2
-- BEGIN;
-- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
INSERT INTO foo (id) --
On Wed, Jun 28, 2006 at 02:48:01PM -0400, Brad Nicholson wrote:
I'm seeing something fairly unintuitive about serializable transactions.
Taking the following test case:
snip
http://www.postgresql.org/docs/8.1/interactive/transaction-iso.html
When a transaction is on the serializable
On Wed, Jun 28, 2006 at 14:48:01 -0400,
Brad Nicholson [EMAIL PROTECTED] wrote:
I'm seeing something fairly unintuitive about serializable transactions.
When a transaction is on the serializable level, a SELECT query sees
only data committed before the transaction began; it never sees
Martijn van Oosterhout kleptog@svana.org writes:
I think the issue here is that transaction begin is not when you type
begin but at your first actual query. You can obviously only start a
transaction once you know what serialisation level you want, and you
don't see that till after the begin.
11 matches
Mail list logo
