olha nao sei o que deu na minha cabeça, uso sequences de dar nojo, é minha
realidade tudo que os Srs. me recomendaram e não sei pq não fiz isso!!!!
Mas mto obrigado, farei dessa forma....
Em 2 de março de 2011 16:31, Marcelo Silva (IG) <marc...@ig.com.br>escreveu:
> 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: marc...@ig.com.br
>
>
>
>
> *From:* Fernando Wobeto <fernandowob...@gmail.com>
> *Sent:* Wednesday, March 02, 2011 4:22 PM
> *To:* Comunidade PostgreSQL Brasileira<pgbr-geral@listas.postgresql.org.br>
> *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
> <eu...@timbira.com>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
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> Fernando Wobeto
> Desenvolvedor Web
> fernandowob...@gmail.com
>
>
> ------------------------------
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
--
Fernando Wobeto
Desenvolvedor Web
fernandowob...@gmail.com
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
