[pgbr-geral] Uso de tablespace
Pessoal, Com a exceção de organização, qual benefício em utilizar tablespace, estando esta no mesmo disco? []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] MFA em PostgreSQL
Bom dia pessoal. Alguém já implementou alguma solução de MFA com PostgreSQL em produção para acesso de usuários? E existe alguma solução que seja integrada com aplicativos mobile como Authy? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Diferença entre campos do tipo string
Existe diferença entre os campos do tipo varchar(n) e text? Fisicamente, não há diferença. Logicamente, o varchar tem a limitação no número de caracteres (n) mas é apenas uma verificação no momento em que se insere ou se altera o valor. Qual seria a limitação de caracteres para estes tipos? 1 GiB, não caracteres, afinal alguns caracteres em algumas codificações são multi-byte. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] MFA em PostgreSQL
Em 15 de abril de 2015 09:29, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Alguém já implementou alguma solução de MFA com PostgreSQL em produção para acesso de usuários? MFA pode ser uma infinidade de coisas. E existe alguma solução que seja integrada com aplicativos mobile como Authy? Você está falando de Multi Factor Authentication? Se sim, explique direito o que quer fazer. Alguns engenheiros tem acesso aos dados de produção, e gostaria de aumentar o nivel de segurança habilitando o Multi Factor Authentication pelo pgAdmin ou PSQL. []s Flavio Gurgel ___ 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
[pgbr-geral] Diferença entre campos do tipo string
Pessoal, Existe diferença entre os campos do tipo varchar(n) e text? Qual seria a limitação de caracteres para estes tipos? []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Diferença entre campos do tipo string
Em 15 de abril de 2015 10:09, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Existe diferença entre os campos do tipo varchar(n) e text? Fisicamente, não há diferença. Logicamente, o varchar tem a limitação no número de caracteres (n) mas é apenas uma verificação no momento em que se insere ou se altera o valor. Qual seria a limitação de caracteres para estes tipos? 1 GiB, não caracteres, afinal alguns caracteres em algumas codificações são multi-byte. Sempre tive essa dúvida, pois até então pensava que o varchar tivesse uma limitação de 255 caracteres, por isso seguia uma regra minha: se o tamanho é fixo e menor que 255 caracteres uso char, se o tamanho for variável de até 255 utilizo varchar, fora isso uso text. Mas por sua resposta estava errado, pois não tem diferenças entre varchar e text, apenas limitação de espaço a ser armazenado. Obrigado. []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de tablespace
Com a exceção de organização, qual benefício em utilizar tablespace, estando esta no mesmo disco? Nenhum. Por acaso você está fazendo alguma prova on-line e obtendo resposta na lista? (curiosidade apenas aqui) []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] MFA em PostgreSQL
Alguém já implementou alguma solução de MFA com PostgreSQL em produção para acesso de usuários? MFA pode ser uma infinidade de coisas. E existe alguma solução que seja integrada com aplicativos mobile como Authy? Você está falando de Multi Factor Authentication? Se sim, explique direito o que quer fazer. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de tablespace
Em 15 de abril de 2015 10:10, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Com a exceção de organização, qual benefício em utilizar tablespace, estando esta no mesmo disco? Nenhum. Por acaso você está fazendo alguma prova on-line e obtendo resposta na lista? (curiosidade apenas aqui) Não, apenas uma dúvida que tinha, pois terei que migrar algumas bases e levantaram a questão de usar tablespace, mas até então disponibilizaram apenas um disco para o postgres. Obrigado. []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
Em 15 de abril de 2015 13:27, Marcos Thomaz marcosthom...@gmail.com escreveu: Em 15 de abril de 2015 11:16, Rosana de Oliveira rosana.pi...@gmail.com escreveu: Boa tarde a todos. Gostaria de que me auxiliassem a resolver uma dúvida sobre o que está ocorrendo na situação de controle de concorrência abaixo. Não me lembro de ter visto esse caso nas literaturas de Banco de Dados. Fizemos testes nas versões 9.3.5 e 9.4 do Postgresql. O cenário consistem de duas transações sendo executadas concorrentemente no Postgresql. A transação TA faz inserção em uma tabela animal. A transação TB faz update na tabela pessoa, em um campo que não tem nada a ver com a chave estrangeira à tabela animal. O que acontece é que o update da transação TB é executado normalmente. Porém, se executarmos um SELECT FOR UPDATE, o Postgresql não aceita e dá mensagem de erro, não conseguindo obter o lock. PERGUNTA-SE: 1. Qual a explicação literária e do Postgresql para esta tentativa mal sucedida de obter o lock? 1.1 Quem 'lockou' o quê? 2. Só de curiosidade, fizemos o mesmo teste no Oracle e não ocorreu erro algum. E agora? Quem poderá nos defender?? rss Segue abaixo o script ... --1.a tabela create table pessoa( codp integer primary key, nome varchar(10) ); --2.a tabela create table animal( coda integer primary key, raca varchar(10), codp integer references pessoa(codp) ); -- inserção de dados insert into pessoa values (1, 'rosa'); insert into pessoa values (2, 'maria'); insert into pessoa values (3, 'josé'); -- transacao - TA begin; insert into animal values (108, 'viralata', 1); select * from animal; select * from pessoa; --transacao -TB begin; update pessoa set nome = 'rosana' where nome = 'rosa'; -- executado com sucesso update pessoa set nome = 'rosa de' where codp=1; -- executado com sucesso select nome from pessoa for update nowait; -- erro! ** Error ** ERROR: could not obtain lock on row in relation pessoa SQL state: 55P03 Atenciosamente, -- Rosana de Oliveira Santos ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Correndo o risco de estar falando besteira, e sem nenhuma comprovação literária, mas quando você dá um update dentro da transação, o registro não ficaria bloqueado? Digo isso porque se a ideia é bloquear até o final da alteração, o ideal seria o uso do select for update antes dos comandos de alteração, garantindo o bloqueio, que seria liberado após a conclusão da transação (commit/rollback). Se o update por si só já bloquear o registro, o select for update iria falhar (pois está sendo colocado depois), não seria isso? -- Marcos Thomaz da Silva Analista de Tecnologia da Informação ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral O nível de isolamento do Postgresql é o read committed. Não sei qual é o do Oracle. Esqueçam-no. Uma resposta da literatura formal (Date, Navathe, Silberchatz) para mim, seria suficiente. Só para explicar, o cenário que coloquei foi totalmente didático. As operações de update, seguido de SELECT for UPDATE não necessariamente precisam estar em sequência. Não é isto que estou questionando. E sim, porque o update funciona e o SELECT FOR UPDATE NÃO? Grata, -- Rosana de Oliveira Santos ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] SELECT FOR UPDATE tentando obter lock
Boa tarde a todos. Gostaria de que me auxiliassem a resolver uma dúvida sobre o que está ocorrendo na situação de controle de concorrência abaixo. Não me lembro de ter visto esse caso nas literaturas de Banco de Dados. Fizemos testes nas versões 9.3.5 e 9.4 do Postgresql. O cenário consistem de duas transações sendo executadas concorrentemente no Postgresql. A transação TA faz inserção em uma tabela animal. A transação TB faz update na tabela pessoa, em um campo que não tem nada a ver com a chave estrangeira à tabela animal. O que acontece é que o update da transação TB é executado normalmente. Porém, se executarmos um SELECT FOR UPDATE, o Postgresql não aceita e dá mensagem de erro, não conseguindo obter o lock. PERGUNTA-SE: 1. Qual a explicação literária e do Postgresql para esta tentativa mal sucedida de obter o lock? 1.1 Quem 'lockou' o quê? 2. Só de curiosidade, fizemos o mesmo teste no Oracle e não ocorreu erro algum. E agora? Quem poderá nos defender?? rss Segue abaixo o script ... --1.a tabela create table pessoa( codp integer primary key, nome varchar(10) ); --2.a tabela create table animal( coda integer primary key, raca varchar(10), codp integer references pessoa(codp) ); -- inserção de dados insert into pessoa values (1, 'rosa'); insert into pessoa values (2, 'maria'); insert into pessoa values (3, 'josé'); -- transacao - TA begin; insert into animal values (108, 'viralata', 1); select * from animal; select * from pessoa; --transacao -TB begin; update pessoa set nome = 'rosana' where nome = 'rosa'; -- executado com sucesso update pessoa set nome = 'rosa de' where codp=1; -- executado com sucesso select nome from pessoa for update nowait; -- erro! ** Error ** ERROR: could not obtain lock on row in relation pessoa SQL state: 55P03 Atenciosamente, -- Rosana de Oliveira Santos ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
Em 15 de abril de 2015 13:56, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: Por favor corte o que não é relevante à sua resposta, facilita quem vai responder. Por favor, seja mais cordial. Fiz uma pergunta e até agora só recebi críticas de você, Guimarães, como resposta. Suas mensagens têm tom apelativo. Se não pode me ajudar, abstenha-se de responder. Não quero fugir do tema. Estou aguardando o tempo que for necessário os demais colegas responderem. -- Rosana de Oliveira Santos ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
Em 15 de abril de 2015 11:16, Rosana de Oliveira rosana.pi...@gmail.com escreveu: Boa tarde a todos. Gostaria de que me auxiliassem a resolver uma dúvida sobre o que está ocorrendo na situação de controle de concorrência abaixo. Não me lembro de ter visto esse caso nas literaturas de Banco de Dados. Fizemos testes nas versões 9.3.5 e 9.4 do Postgresql. O cenário consistem de duas transações sendo executadas concorrentemente no Postgresql. A transação TA faz inserção em uma tabela animal. A transação TB faz update na tabela pessoa, em um campo que não tem nada a ver com a chave estrangeira à tabela animal. O que acontece é que o update da transação TB é executado normalmente. Porém, se executarmos um SELECT FOR UPDATE, o Postgresql não aceita e dá mensagem de erro, não conseguindo obter o lock. PERGUNTA-SE: 1. Qual a explicação literária e do Postgresql para esta tentativa mal sucedida de obter o lock? 1.1 Quem 'lockou' o quê? 2. Só de curiosidade, fizemos o mesmo teste no Oracle e não ocorreu erro algum. E agora? Quem poderá nos defender?? rss Segue abaixo o script ... --1.a tabela create table pessoa( codp integer primary key, nome varchar(10) ); --2.a tabela create table animal( coda integer primary key, raca varchar(10), codp integer references pessoa(codp) ); -- inserção de dados insert into pessoa values (1, 'rosa'); insert into pessoa values (2, 'maria'); insert into pessoa values (3, 'josé'); -- transacao - TA begin; insert into animal values (108, 'viralata', 1); select * from animal; select * from pessoa; --transacao -TB begin; update pessoa set nome = 'rosana' where nome = 'rosa'; -- executado com sucesso update pessoa set nome = 'rosa de' where codp=1; -- executado com sucesso select nome from pessoa for update nowait; -- erro! ** Error ** ERROR: could not obtain lock on row in relation pessoa SQL state: 55P03 Atenciosamente, -- Rosana de Oliveira Santos ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Correndo o risco de estar falando besteira, e sem nenhuma comprovação literária, mas quando você dá um update dentro da transação, o registro não ficaria bloqueado? Digo isso porque se a ideia é bloquear até o final da alteração, o ideal seria o uso do select for update antes dos comandos de alteração, garantindo o bloqueio, que seria liberado após a conclusão da transação (commit/rollback). Se o update por si só já bloquear o registro, o select for update iria falhar (pois está sendo colocado depois), não seria isso? -- Marcos Thomaz da Silva Analista de Tecnologia da Informação ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
Por favor corte o que não é relevante à sua resposta, facilita quem vai responder. 2015-04-15 13:47 GMT-03:00 Rosana de Oliveira rosana.pi...@gmail.com: O nível de isolamento do Postgresql é o read committed. Não sei qual é o do Oracle. O padrão do Oracle me parece ser o mesmo. Esqueçam-no. Por quê? Às vezes é mais fácil lembrar dos níveis de isolamento comparando o comportamento que direto dos conceitos. Uma resposta da literatura formal (Date, Navathe, Silberchatz) para mim, seria suficiente. Claro. Só não está fresco na minha mente, e não posso parar para relembrar aqui. Tenha um pouco de paciência, normalmente esse tipo de pergunta é respondido na lista no mesmo dia, talvez no seguinte. Só para explicar, o cenário que coloquei foi totalmente didático. Nem precisava explicar isso, até pelas relações extremamente simples e sem chaves naturais. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
Correndo o risco de estar falando besteira, e sem nenhuma comprovação literária, mas quando você dá um update dentro da transação, o registro não ficaria bloqueado? Digo isso porque se a ideia é bloquear até o final da alteração, o ideal seria o uso do select for update antes dos comandos de alteração, garantindo o bloqueio, que seria liberado após a conclusão da transação (commit/rollback). Se o update por si só já bloquear o registro, o select for update iria falhar (pois está sendo colocado depois), não seria isso? -- Sim é verdade, mas no exemplo ditático acima... por que o SELECT FOR UPDATE tentou obter lock? Pelo que eu entendi e testei cada teste da trasação 2 esta sendo feito isoladamente, não tem nada haver com update na mesma transação. Sendo assim, minha dúvida é a mesma. Atenciosamente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
Por favor, evite mensagens HTML. Ler código em Comic Sans não é muito agradável… 2015-04-15 13:16 GMT-03:00 Rosana de Oliveira rosana.pi...@gmail.com: 2. Só de curiosidade, fizemos o mesmo teste no Oracle e não ocorreu erro algum. Quais os respectivos níveis de isolamento? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
Em 15 de abril de 2015 13:16, Rosana de Oliveira rosana.pi...@gmail.com escreveu: PERGUNTA-SE: 1. Qual a explicação literária e do Postgresql para esta tentativa mal sucedida de obter o lock? Eu passei por isso a um tempo atrás e tinha a ver com prepared transactions. dá uma olhada na doc[1]. 1.1 Quem 'lockou' o quê? Qual é o conteudo da view pg_locks? Tens como mandar a saida antes e depois de iniciar o teu teste? 2. Só de curiosidade, fizemos o mesmo teste no Oracle e não ocorreu erro algum. E agora? Quem poderá nos defender?? Sem dúvida, o Chapolin Colorado! [1] http://www.postgresql.org/docs/9.4/static/view-pg-locks.html -- Sebastian Webber http://swebber.me ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Função retorna chave composta
Uma função deve inserir um registro em uma tabela e retornar a PK do registro inserido, porém, a PK da tabela é uma chave composta. Qual deve ser o tipo de retorno da função e como fazer o retormo? Exemplo: TBLCONTA - cliente integer PK tipoconta smallint PK banco varchar(30) agencia varchar(10) conta varchar(10) Em uma chave simples eu posso usar a clausula RETURNING do INSERT para obter a PK do registro inserido. Mas como fazer isso com uma chave composta? Eu pensei em criar um tipo composto com os tipos (integer e smallint), e usar como sendo o retorno da função mas como fazer o retorno do corpo da mesma? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: SELECT FOR UPDATE tentando obter lock
--1.a tabela create table pessoa( codp integer primary key, nome varchar(10) ); --2.a tabela create table animal( coda integer primary key, raca varchar(10), codp integer references pessoa(codp) ); -- inserção de dados insert into pessoa values (1, 'rosa'); insert into pessoa values (2, 'maria'); insert into pessoa values (3, 'josé'); -- transacao - TA begin; insert into animal values (108, 'viralata', 1); select * from animal; select * from pessoa; --transacao -TB begin; update pessoa set nome = 'rosana' where nome = 'rosa'; -- executado com sucesso update pessoa set nome = 'rosa de' where codp=1; -- executado com sucesso select nome from pessoa for update nowait; -- erro! ** Error ** ERROR: could not obtain lock on row in relation pessoa SQL state: 55P03 Testei o script exatamente como vc postou aqui, mas não obtive este lock. Minha versão do postgres é 9.3.2. Na versão 9.0 o comando: update pessoa set nome = 'rosana' where nome = 'rosa'; fica aguardando a transação anterior. Att. Márcio A. Sepp ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
On 15-04-2015 13:16, Rosana de Oliveira wrote: 1. Qual a explicação literária e do Postgresql para esta tentativa mal sucedida de obter o lock? Vamos entender o que ocorreu na transação A. begin; insert into animal values (108, 'viralata', 1); euler=# select relation::regclass,locktype,virtualtransaction as vtxn,pid,mode from pg_locks order by pid,relation; relation | locktype| vtxn | pid | mode -+---+--+--+-- pessoa | relation | 2/21 | 2794 | RowShareLock pessoa_pkey | relation | 2/21 | 2794 | AccessShareLock animal | relation | 2/21 | 2794 | RowExclusiveLock | virtualxid| 2/21 | 2794 | ExclusiveLock | transactionid | 2/21 | 2794 | ExclusiveLock A inserção foi na tabela animal mas como há uma chave estrangeira para tabela pessoa, o SGBD tem que garantir que ninguém irá modificar o registro envolvido (por isso ele coloca um RowShareLock na tabela pessoa). 1.1 Quem 'lockou' o quê? Na segunda transação: euler=# begin; BEGIN euler=# select nome from pessoa for update; euler=# select relation::regclass,locktype,virtualtransaction as vtxn,pid,mode from pg_locks order by pid,relation; relation | locktype| vtxn | pid |mode -+---+--+--+- pessoa | relation | 3/41 | 2728 | RowShareLock pessoa | tuple | 3/41 | 2728 | AccessExclusiveLock pessoa_pkey | relation | 3/41 | 2728 | AccessShareLock | transactionid | 3/41 | 2728 | ShareLock | virtualxid| 3/41 | 2728 | ExclusiveLock pessoa | relation | 2/21 | 2794 | RowShareLock pessoa_pkey | relation | 2/21 | 2794 | AccessShareLock animal | relation | 2/21 | 2794 | RowExclusiveLock | transactionid | 2/21 | 2794 | ExclusiveLock | virtualxid| 2/21 | 2794 | ExclusiveLock [não usei o NOWAIT para deixar a transação B esperando para que eu possa obter a saída dos locks] O SELECT ... FOR UPDATE tenta obter um AccessExclusiveLock (segunda linha) em todas as tuplas da tabela mas isso não é possível porque uma das tuplas (codp = 1) está com um lock FOR KEY SHARE (vide tabela 13-3 em [1]) para impossibilitar alguém de alterar o codp da tupla 1 ou mesmo remover a tupla 1 (essa garantia é necessária para manter a integridade dos dados). 2. Só de curiosidade, fizemos o mesmo teste no Oracle e não ocorreu erro algum. E agora? Quem poderá nos defender?? rss Muito estranho ele não falhar (no caso do NOWAIT) ou ficar esperando (sem NOWAIT) pois isso pode acarretar perda de integridade. O que acontece se na transação B você alterar o codp de 1 para 2? Vale ressaltar que em versões anteriores a 9.3, UPDATE em tuplas de uma chave estrangeira (como é o caso dos seus UPDATEs na transação B) ficam bloqueados. A partir da 9.3, eles podem ser feitos desde que você *não* altere a chave primária da tabela pessoa. [1] http://www.postgresql.org/docs/9.4/static/explicit-locking.html -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
2015-04-15 13:16 GMT-03:00 Rosana de Oliveira rosana.pi...@gmail.com: 1. Qual a explicação literária e do Postgresql para esta tentativa mal sucedida de obter o lock? O erro especificamente foi devido ao parâmetro NOWAIT, se removesse este, a segunda transação ficaria bloqueada aguardando a primeira. 1.1 Quem 'lockou' o quê? Ok, vamos simplificar o exemplo para entender melhor: * Preparação (igual ao seu): CREATE TABLE pessoa(codp integer RIMARY KEY, nome varchar(10)); CREATE TABLE animal(coda integer PRIMARY KEY, raca varchar(10), codp integer REFERENCES pessoa(codp)); INSERT INTO pessoa VALUES (1, 'rosa'); INSERT INTO pessoa VALUES (2, 'maria'); INSERT INTO pessoa VALUES (3, 'josé'); * Transação TA: BEGIN; INSERT INTO animal VALUES (108, 'viralata', 1); * Transação TB: BEGIN; SELECT * FROM pessoa FOR UPDATE NOWAIT; -- ERRO! O que aconteceu foi, quando você fez o INSERT de animal na TA, o PostgreSQL bloqueou a tupla que esta se refere na tabela pessoa, nesse caso a que possue codp = 1, isso para garantir que a chave estrangeira não seja removida durante a operação. Internamente o PostgreSQL usa o seguinte comando quando você faz o INSERT: SELECT 1 FROM ONLY pessoa x WHERE x.codp = 1 FOR KEY SHARE OF x; E quando você executou o SELECT em TB, você incluiu a linha com codp=1, que já estava bloqueado pelo comando acima (executado implicitamente com o INSERT), causando assim um conflito e, como usou o NOWAIT, retornando um erro. Se quiser verificar isso, exclua o codp=1 do SELECT em TB e verá que o erro não é retornado: SELECT * FROM pessoa WHERE codp 1 FOR UPDATE NOWAIT; Se você está usando FOR UPDATE, mas sabe que não vai alterar nenhuma chave UK/PK da tabela, você pode usar o FOR NO KEY UPDATE, que é mutuamente exclusivo mas não conflita com FOR KEY SHARE (usando pelas chaves estrangeiras). Veja os demais níveis em [1]. OBS: FOR KEY SHARE é relativamente novo, 9.3 se não me engano. [1] http://www.postgresql.org/docs/current/static/explicit-locking.html#LOCKING-ROWS Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função retorna chave composta
2015-04-15 15:45 GMT-03:00 Matheus Saraiva matheus.sara...@gmail.com: Uma função deve inserir um registro em uma tabela e retornar a PK do registro inserido, porém, a PK da tabela é uma chave composta. Qual deve ser o tipo de retorno da função e como fazer o retormo? Exemplo: TBLCONTA - cliente integer PK tipoconta smallint PK banco varchar(30) agencia varchar(10) conta varchar(10) Eu usaria parâmetros OUT, exemplo: CREATE FUNCTION sua_funcao(p_banco varchar, p_agencia varchar, p_conta varchar, OUT p_cliente integer, OUT p_tipoconta smallint) LANGUAGE plpgsql AS $$ BEGIN INSERT INTO tblconta(...) VALUES() RETURNING cliente, tipoconta INTO p_cliente, p_tipoconta END; $$; Assim sua função retorna na saída os valores que estiverem em p_cliente e p_tipoconta, ou seja, ela irá retornar uma linha e duas colunas. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função retorna chave composta
Em Qua, 2015-04-15 às 16:10 -0300, Fabio Roberto escreveu: Em 15 de abril de 2015 15:45, Matheus Saraiva matheus.sara...@gmail.com escreveu: Em uma chave simples eu posso usar a clausula RETURNING do INSERT para obter a PK do registro inserido. Mas como fazer isso com uma chave composta? Opa Matheus, Mas você também pode utilizar o returning numa chave composta também. Por exemplo: insert into TBLCONTA values (1,'1') returning cliente, tipoconta; Isto trará o resultado desejado. U.. Eu lembro de ter tando fazer isso em outra situação mas recebi um erro de sintaxe. Mas, conseguindo pegar os dois valores com RETURNING, como eu faria a função retorná-los? Li alguma coisa sobre retornos RECORD, mas não encontre ainda uma forma de usar RECORD para resolver isso. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função retorna chave composta
Em 15 de abril de 2015 15:45, Matheus Saraiva matheus.sara...@gmail.com escreveu: Em uma chave simples eu posso usar a clausula RETURNING do INSERT para obter a PK do registro inserido. Mas como fazer isso com uma chave composta? Opa Matheus, Mas você também pode utilizar o returning numa chave composta também. Por exemplo: insert into TBLCONTA values (1,'1') returning cliente, tipoconta; Isto trará o resultado desejado. Fábio Roberto de Araújo e Vasconcelos Administrador de Banco de Dados Especialista em Banco de Dados Tecnólogo em Redes de Computadores - IFPB ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Ajuda com trigger
Preciso criar uma trigger em uma tabela que faça inserts/updates nela mesma. Como faço para resolver o problema do loop? Att. Márcio A. Sepp ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ajuda com trigger
Em 15 de abril de 2015 19:38, Márcio A. Sepp mar...@zyontecnologia.com.br escreveu: Preciso criar uma trigger em uma tabela que faça inserts/updates nela mesma. Como faço para resolver o problema do loop? Att. Márcio A. Sepp ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Procure por pg_trigger_depth() [1] http://www.postgresql.org/docs/9.2/static/functions-info.html [2] http://www.depesz.com/2012/02/01/waiting-for-9-2-trigger-depth/ -- Marcos Thomaz da Silva Analista de Tecnologia da Informação ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
Muito obrigada pela explicação, Euler! Show de bola!!! Imaginava que o SGBD controlaria somente reativamente para o controle da restrição de integridade referencial. Nesse caso ele prefere agir preventivamente. Caso contrário, ele precisaria implementar um lock por atributo e não por tupla, não é mesmo? Acredito que ele prefere exceder no zelo com essa ação preventiva e lockar a tupla toda... Muito estranho ele (Oracle) não falhar (no caso do NOWAIT) ou ficar esperando (sem NOWAIT) pois isso pode acarretar perda de integridade. O que acontece se na transação B você alterar o codp de 1 para 2? Mais um ponto para o Postgresql então!!! Vale ressaltar que em versões anteriores a 9.3, UPDATE em tuplas de uma chave estrangeira (como é o caso dos seus UPDATEs na transação B) ficam bloqueados. A partir da 9.3, eles podem ser feitos desde que você *não* altere a chave primária da tabela pessoa. isso aconteceu conosco também na versão 9.2 Obrigada novamente! Rosana de Oliveira Santos ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
Em 15 de abril de 2015 17:33, Matheus de Oliveira matioli.math...@gmail.com escreveu: Obrigada pela explicação Matheus Valeu demais !!! Esse grupo é mesmo muito eficiente! Att. Rosana de Oliveira Santos ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
