Re: Lock strategies! - Mailing list pgsql-general

From MaRCeLO PeReiRA
Subject Re: Lock strategies!
Date
Msg-id 20031124161846.34009.qmail@web20211.mail.yahoo.com
Whole thread Raw
In response to Re: Lock strategies!  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: Lock strategies!
List pgsql-general
Hi Dave, Marc and all others,

I know it is really weird!

But, how can I explain to the user, who use the
sequence numbers, that he will have to handle with
those holes?

Ok! I will try to handle the holes! (fight against the
users)

Thanks!

Marcelo


 --- Dave Cramer <pg@fastcrypt.com> escreveu: >
Marcelo,
>
> You are asking for the impossible.
>
> In order for sequences to work reliably they have to
> exist outside of a
> transaction, and be atomic. If two transactions
> asked for a sequence
> simultaneously, what number would you give them? If
> the first one gets
> 1, and the second gets 2 how do you roll back the
> first one and then
> give the second one 1?
>
> And it gets worse, what happens if 10 connections
> ask for one
> simultaneously and then connection 3 7 rollback?
>
> I don't know how to say this gently, but usually
> this requirement
> suggests that more thinking is required on the
> application end.
>
> Dave
>
>
>
> On Mon, 2003-11-24 at 10:48, MaRcElO PeReIrA wrote:
> > Dave,
> >
> > I actually use just the sequence, as you wrote!
> >
> > The biggest problem it that I *can't* have holes
> in
> > that column, so it was because I used id (serial)
> and
> > forn_id (integer).
> >
> > All other tables use only the sequence by itself,
> but
> > this one, especially, CAN'T have holes! It is the
> > problem!!! ;-)
> >
> > So, if I rollback or whatever, the ID will be
> > populated with the sequence values, but the
> forn_id
> > must increase in a controled way, ie, without
> holes!
> >
> > Advices??????
> >
> > Regards!
> >
> > Marcelo
> >
> >  --- Dave Cramer <pg@fastcrypt.com> escreveu: >
> > Marceio
> > >
> > >
> > >
> > > The sequence logic takes care of it. try it
> yourself
> > >
> > > open two connections with psql
> > >
> > > on one do a
> > > begin;
> > > insert into table
> > > select curval('forn_id_seq');
> > >
> > > on the other
> > >
> > > do a
> > > begin
> > > insert into table
> > > select curval('forn_id_seq');
> > >
> > >
> > > You will see that they both increment the
> sequence
> > > number
> > >
> > > you will also see how to get the current value
> as
> > > well.
> > >
> > > Note, no locking is actually required, you can
> do
> > > this without the
> > > transaction stuff, it is there just so you can
> see
> > > it in two sessions at
> > > the same time.
> > >
> > > Also note that a rollback will NOT roll back the
> > > sequence number, this
> > > will end up with holes but sequences are not
> > > guaranteed to not have
> > > holes.
> > >
> > > Why do you have two columns, id, and forn_id,
> you
> > > only need one.
> > >
> > > and then do an
> > >
> > > insert into forn (descrip) values ( 'some
> > > description' );
> > > then select curval('forn_id_seq');
> > >
> > > forn_id will be populated for you with the value
> > > from curval.
> > >
> > >
> > > Dave
> > >
> > > On Mon, 2003-11-24 at 08:20, MaRcElO PeReIrA
> wrote:
> > > > Hi guys,
> > > >
> > > > I have a simple table:
> > > >
> > > > teste=# \d forn
> > > >                            Table "public.forn"
> > > >  Column  |  Type   |
> > > Modifiers
> > > >
> > >
> >
>
---------+---------+------------------------------------------------------
> > > >  id      | integer | not null default
> > > > nextval('public.forn_id_seq'::text)
> > > >  forn_id | integer |
> > > >  descrip | text    |
> > > >
> > > > Ok! The forn_id is supposed to be sequencial
> and
> > > > without holes (if someone perform a DELETE or
> > > UPDATE,
> > > > so there will be a hole... no problem if the
> hole
> > > > happens in this case!).
> > > >
> > > > Well, to know the next value of the forn_id
> > > column, it
> > > > was planned to be done like this:
> > > >
> > > > teste=# INSERT INTO forn (forn_id,descrip)
> VALUES
> > > > ((SELECT max(forn_id) FROM forn),'descrip1');
> > > >
> > > > It will cause a huge delay in case this table
> > > became
> > > > huge, because the forn_id isn't an indexed
> column
> > > (but
> > > > I would index it! The problem I am talking
> about
> > > is
> > > > ONLY about the sequence of numbers).
> > > >
> > > > As a way to be sure it will not another other
> > > client
> > > > getting the exact value as the max(forn_id),
> there
> > > was
> > > > a dirty thing:
> > > >
> > > > teste=# BEGIN;
> > > > teste=# LOCK TABLE forn IN ACCESS EXCLUSIVE
> MODE;
> > > > teste=# INSERT INTO ...
> > > > teste=# COMMIT;
> > > >
> > > > Well, I really think it is not the best way to
> do
> > > that
> > > > and I am asking you for advices!
> > > >
> > > > 1) Is it (... max(forn_id)... ) the best way
> to
> > > get
> > > > the next value to be inserted in the table?
> > > >
> > > > 2) Is there a automatic way to do that?
> > > >
> > > > Thanks in advance and
> > > > Best Regards,
> > > >
> > > > Marcelo
> > > >
> > > >
> > >
> >
>
______________________________________________________________________
> > > >
> > > > Yahoo! Mail: 6MB, anti-spam e antivírus
> gratuito!
> > > Crie sua conta agora:
> > > > http://mail.yahoo.com.br
> > > >
>
=== message truncated ===

Yahoo! Mail - 6MB, anti-spam e antivírus gratuito. Crie sua conta agora:
http://mail.yahoo.com.br

pgsql-general by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Lock strategies!
Next
From: Jeff
Date:
Subject: Re: Lock strategies!