Sim Zacks <[EMAIL PROTECTED]> writes:
> Here is a simple, reproducible example that delete doesn't cause it to use
> serial:
If you add
raise notice 'past the delete';
between the DELETE and the insert loop, you will discover that the
second guy in fact doesn't manage to complete the DELE
I wonder if you set the transaction mode to "serializable" whether that
would make a difference. In standard read-committed the way it works
below seems to be what's expected (each transaction sees what was
committed at the time is ran).
I tried running this in both windows at the same time (
On Mon, Sep 18, 2006 at 10:31:26AM +0200, Sim Zacks wrote:
> > I think the reason you are seeing failures in the first function is
> > that the initial DELETE is a no-op so it doesn't serialize anything,
> > and then there is conflict when the two INSERTs proceed in parallel.
>
> Here is a simple,
> I think the reason you are seeing failures in the first function is
> that the initial DELETE is a no-op so it doesn't serialize anything,
> and then there is conflict when the two INSERTs proceed in parallel.
Here is a simple, reproducible example that delete doesn't cause it to use
serial:
c
> I think the reason you are seeing failures in the first function is
> that the initial DELETE is a no-op so it doesn't serialize anything,
> and then there is conflict when the two INSERTs proceed in parallel.
There is always data in the table that it deletes. So, according to that, with the fi
Sim Zacks <[EMAIL PROTECTED]> writes:
> This function, when run in 2 separate sessions at the same time,
> causes a duplicate key error because popartid is a primary key.
> ...
> The next one is a bit longer. I would expect that if it was run in 2
> separate sessions that 1) it would generate the s
This function, when run in 2 separate sessions at the same time, causes a duplicate key error
because popartid is a primary key. This makes sense to me. When the function is run in the second
session it doesn't know about the transaction currently running in the first session. Therefore,
when it
On Sun, Sep 17, 2006 at 10:32:12AM +0200, Sim Zacks wrote:
> I have a function that deletes all the values in a table and then
> inserts the data again. If this function is run in 2 sessions at the
> same time then it populates it twice, giving me a unique value error,
> because one of the field
I have a function that deletes all the values in a table and then
inserts the data again. If this function is run in 2 sessions at the
same time then it populates it twice, giving me a unique value error,
because one of the fields is supposed to be unique.
I understand this because the second ti
