Tsirkin Evgeny wrote:
> On Mon, 6 Sep 2004, Michael Paesold wrote:
> Does not the Serializable Isolation Level do insure that?
> what i thought is that while using this level then i am getting
> the BEGIN and COMMIT to behave the same as the code you wrote!
> since the second concarent transaction
Tsirkin Evgeny wrote:
> one moer question ,how did you tested it?
>
> > I have tested this here. I don't really know if this is just the case
with
> > Best Regards,
> > Michael Paesold
First I created the your schedule table. Then I opened two psql sessions...
Session ASession B
No, you should lock the table.
I mean that you can select or insert into that table even if a
transaction is running.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Tsirkin Evgeny wrote:
yes i understand that i can create a primary key/unique etc...
however my question is if i have to understand if and why
the i got duplicate rows inserted.
so here is the picture:
an application is deleting rows and inserting right after that
new ones some of which are the sam
If the reccord you are inserting do not depend on data in the record you
want to delete, why not simply use a trigger?
Before insert delete the record with the same key!
Michael Paesold wrote:
Tsirkin Evgeny wrote:
one moer question ,how did you tested it?
I have tested this here. I don't real
Tsirkin Evgeny wrote:
> one moer question ,how did you tested it?
>
> > I have tested this here. I don't really know if this is just the case
with
> > Best Regards,
> > Michael Paesold
First I created the your schedule table. Then I opened two psql sessions...
Session ASession B
one moer question ,how did you tested it?
> I have tested this here. I don't really know if this is just the case with
> Best Regards,
> Michael Paesold
>
>
> ---(end of broadcast)---
> TIP 8: explain analyze is your friend
>
--
Evgeny.
---
You are greate Michael!
Thanks.
On Mon, 6 Sep 2004, Michael Paesold wrote:
> I wrote:
>
> > BEGIN;
> > SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> >
> > DELETE FROM schedule WHERE studentid = ... ;
> > INSERT INTO schedule (studentid, ...) VALUES (... );
> > INSERT INTO schedule (studentid,
I wrote:
> BEGIN;
> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
>
> DELETE FROM schedule WHERE studentid = ... ;
> INSERT INTO schedule (studentid, ...) VALUES (... );
> INSERT INTO schedule (studentid, ...) VALUES (... );
>
> COMMIT;
>
> If you do it like in the above sql code, there is still a
Tsirkin Evgeny wrote:
> On Mon, 6 Sep 2004, Michael Paesold wrote:
> Does not the Serializable Isolation Level do insure that?
> what i thought is that while using this level then i am getting
> the BEGIN and COMMIT to behave the same as the code you wrote!
> since the second concarent transaction
- Original Message -
From: "Tsirkin Evgeny" <[EMAIL PROTECTED]>
To: "Andrei Bintintan" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, September 06, 2004 12:19 PM
Subject: Re: [ADMIN] duplicates
> yes i understand that i can create
yes i understand that i can create a primary key/unique etc...
however my question is if i have to understand if and why
the i got duplicate rows inserted.
so here is the picture:
an application is deleting rows and inserting right after that
new ones some of which are the same as the old one,and i
- Original Message -
From: "Tsirkin Evgeny" <[EMAIL PROTECTED]>
To: "Andrei Bintintan" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, September 06, 2004 10:57 AM
Subject: Re: [ADMIN] duplicates
> On Mon, 6 Sep 2004, Andrei Bintintan w
On Mon, 6 Sep 2004, Andrei Bintintan wrote:
> If still got problems, please post some queries, be more specific.
>
> Best regards,
> Andy.
>
Ok i will try:
CREATE TABLE schedule (
studentiddecimal(9),
groupid decimal(10),
maslulsignid decimal(7),
tfusot
PROTECTED]>
Sent: Monday, September 06, 2004 9:33 AM
Subject: [ADMIN] duplicates
> Hello dear list!
> Here is the problem i have:
> i am using 7.3.4 postgres .i have an aplication that updating 2 tables.
> while it needs to update something - it does not select the rows that
> are al
Hello dear list!
Here is the problem i have:
i am using 7.3.4 postgres .i have an aplication that updating 2 tables.
while it needs to update something - it does not select the rows that
are already in the table search what it needs to update and execute
an 'update' query .in place it deletes all
16 matches
Mail list logo