Poderá usar um generator pra pegar uma sequencial:
CREATE SEQUENCE codigo_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 1
CACHE 1;
Isso irá criar uma chave sequencial
Depois pra pegar o valor é só fazer
select nextval('codigo_seq'::regclass) as cod_seq
Isso é bem mais seguro que qualquer sequencial em tabela, haja visto que não ha
concorrencia, pois a cada acesso ele ja incrementa 1 e recupera o valor na
mesma transação.
Marcelo Silva
---------------------------------
msn: [email protected]
From: Fernando Wobeto
Sent: Wednesday, March 02, 2011 4:22 PM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] lock table (deixando travada a tabela)
o unico motivo que me fez pensar em usar o LOCK foi por exemplo que um certo
script PHP precise pegar o ultimo codigo +1 em uma tabela.
Após começa a fazer update em outras tabelas usando tal codigo como referencia
e no final de tudo gera realmente um registro na primeira tabela com o codigo.
O problema é que podemos ter em outra estação algum usuário efetuando o mesmo
procedimento, então ele pegaria o mesmo codigo+1 e jogaria nos seus registros
esse código.
Qual seria a alterativa fora o LOCK?
Muito obrigado pela presteza.
Fernando
Em 2 de março de 2011 16:12, Euler Taveira de Oliveira <[email protected]>
escreveu:
Em 02-03-2011 15:28, Fernando Wobeto escreveu:
> pg_query('BEGIN');
> pg_query('LOCK TABLE tabela1');
> pg_query('SELECT codigo +1 FROM tabela1');
> pg_query('INSERT INTO tabela2(var1,var2,var3,var4)VALUES(1,2,3,4,5)');
> pg_query('UPDATE tabela3 SET var1=1');
> pg_query('COMMIT');
>
>
> por qual motivo um codigo desses no final das contas deixaria a tabela1
> travada por causa do lock.
>
O COMMIT ou ROLLBACK não ser executado? O tempo de espera (timeout) da página
web é alto após o pedido de cancelamento pelo usuário? Algum deadlock causado
por outra sessão fazendo um travamento nas tabelas tabela2 ou tabela3?
Eu não aconselharia o uso do LOCK TABLE. Ele causa muito mal para uma
aplicação que permite o acesso concorrente dos dados (quase todas hoje em
dia). Aconselho-te pensar novamente se isso é realmente necessário.
--
Euler Taveira de Oliveira
http://www.timbira.com/
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
Fernando Wobeto
Desenvolvedor Web
[email protected]
--------------------------------------------------------------------------------
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
