Lock strategies! - Mailing list pgsql-general

From MaRcElO PeReIrA
Subject Lock strategies!
Date
Msg-id 20031124132007.3208.qmail@web20208.mail.yahoo.com
Whole thread Raw
Responses Re: Lock strategies!  ("Marc A. Leith" <marc@redboxdata.com>)
Re: Lock strategies!  (Jeff <threshar@torgo.978.org>)
Re: Lock strategies!  (Dave Cramer <pg@fastcrypt.com>)
List pgsql-general
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

pgsql-general by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: building 7.4 with plperl
Next
From: Tom Lane
Date:
Subject: Re: Declaring empty, non-NULL array in plpgsql