Hi, Andreq,
Andrew Sullivan wrote:
> I think you don't have a clear idea of what locks are necessary for
> updates. Write operations on a row must block other write operations
> on the same row. If more than one transaction needs the same kinds
> of locks on two different tables, but attempts t
On Thu, Jan 26, 2006 at 01:51:27PM +0100, Markus Schaber wrote:
> Hmm, are you shure that this is correct? The delete will always delete 0
> rows.
Quite, and no it won't. The contrived example is actually a
simplification of a case one of our developers implemented. The
conflict is on the update
On Thu, 26 Jan 2006, Markus Schaber wrote:
> AFAIK, in PostgreSQL normal SQL commands cannot create deadlocks at all,
> the only way to introduce deadlocks is to issue LOCK commands to take
> locks manually. And for this rare case, PostgreSQL contains a deadlock
> detection routine that will abo
Hi, Andrew,
Andrew Sullivan wrote:
>>AFAIK, in PostgreSQL normal SQL commands cannot create deadlocks at all,
>>the only way to introduce deadlocks is to issue LOCK commands to take
>>locks manually. And for this rare case, PostgreSQL contains a deadlock
>>detection routine that will abort one of
On Thu, Jan 26, 2006 at 10:42:54AM +0100, Markus Schaber wrote:
> AFAIK, in PostgreSQL normal SQL commands cannot create deadlocks at all,
> the only way to introduce deadlocks is to issue LOCK commands to take
> locks manually. And for this rare case, PostgreSQL contains a deadlock
> detection ro
Hi, Mario,
My explanation is a little longer, as I think I must at least basically
explain some of the fundamentals of database synchronization.
Mario Splivalo wrote:
>>>Is it possible to change the transaction level within the procedure?
>>No, currently not, the PostgreSQL "stored procedures" r
Hi, Mario,
Mario Splivalo wrote:
>>you need to set the transaction level after the begin and before every
>>other statement... after the begin you have a select that invoke your
>>function so that set is not the first statement...
>
> But I can't do that inside of a function, right?
Right, as y
On Wed, 2006-01-25 at 15:54 +0100, Markus Schaber wrote:
> Hi, Mario,
>
> Mario Splivalo wrote:
> > Is it possible to change the transaction level within the procedure?
>
> No, currently not, the PostgreSQL "stored procedures" really are "stored
> functions" that are called inside a query, and th
On Wed, 2006-01-25 at 11:46 -0500, Jaime Casanova wrote:
> you need to set the transaction level after the begin and before every
> other statement... after the begin you have a select that invoke your
> function so that set is not the first statement...
But I can't do that inside of a function,
> 1. java got the message via http (whatever)
> 2. java does: begin;
> 3. java does: select * from create_message(...)
> 4. java does some checking
> 5. java does: select * from set_message_status(...)
> 6. java does some more checing
> 7. java does commit; (under rare circumstances java does rollb
Hi, Mario,
Mario Splivalo wrote:
> Is it possible to change the transaction level within the procedure?
No, currently not, the PostgreSQL "stored procedures" really are "stored
functions" that are called inside a query, and thus cannot contain inner
transactions.
> I'm using Postgres 8.1.2 defau
Is it possible to change the transaction level within the procedure?
I'm using Postgres 8.1.2 default isolation level. But, I would like one
stored procedure to execute as in serializable isolation level. I have
created my stored procedure like this:
CREATE OR REPLACE FUNCTION set_message_status(
12 matches
Mail list logo
