[pgbr-geral] PESQUISAR HISTÓRICO

[MIGUEL JOSE DE LIMA]

Por favor, qual a url para pesquisa do histórico da lista.

Tentei no histórico do site, mas diz que página não existe
  "...Antes de fazer qualquer pergunta, pesquise no histórico
 para verificar se sua dúvida já
foi respondida."
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] REPLICAÇÃO - Record with incorrect prev-link

[MIGUEL JOSE DE LIMA]

Em 12 de janeiro de 2017 15:00, Euler Taveira <eu...@timbira.com.br>
escreveu:

> On 12-01-2017 13:54, MIGUEL JOSE DE LIMA wrote:
> > Senhores, em uma replicação nativa master/slave apareceu o erro:
> > "record with incorrect prev-link B/BBD4FF30 at B/C0D4FF78" no slave.
> > Apenas um master e um slave
> >
> >>O erro não tem haver com o assunto. Veja que essa mensagem é LOG.
>
Sim mas é estranho, podendo levar a outras interpretações para mim, com
pouco conhecimento.
Valeu.

>
> A causa do problema é:
>
> > 2017-01-06 18:51:03 BRST [2132]: [2-1] user=, db= FATAL:  terminating
> > walreceiver due to timeout
> >
> >>Verifique as credenciais de conexão (primary_conninfo) e também a
> >>conexão entre as máquinas.
>
A replicação continua funcionando normalmente, ou seja, minha conexão está
ok.
recovery.conf:
standby_mode = on
primary_conninfo = 'host=10.1.0.215 port=5433 user=usrreplica
password=inloc@replica application_name=slave0'
trigger_file = '/tmp/psql.trigger'

Então pergunto novamente: se replicação continuou funcionando normalmente,
quer dizer que esse erro fatal foi ignorado posteriormente?
Os logs posteriores, tanto do master e slave, não tem nenhuma mensagem
relevante!
Obrigado.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] REPLICAÇÃO - Record with incorrect prev-link

[MIGUEL JOSE DE LIMA]

Senhores, em uma replicação nativa master/slave apareceu o erro:
"record with incorrect prev-link B/BBD4FF30 at B/C0D4FF78" no slave.
Apenas um master e um slave

Log do Server (SLAVE):

2017-01-06 13:06:45 BRST [1883]: [1-1] user=, db= LOG:  database system was
interrupted while in recovery at log time 2017-01-06 12:39:03 BRST
2017-01-06 13:06:45 BRST [1883]: [2-1] user=, db= HINT:  If this has
occurred more than once some data might be corrupted and you might need to
choose an earlier recovery target.
2017-01-06 13:06:46 BRST [1883]: [3-1] user=, db= LOG:  entering standby
mode
2017-01-06 13:06:46 BRST [1883]: [4-1] user=, db= LOG:  redo starts at
B/C0CED7C0
2017-01-06 13:06:46 BRST [1883]: [5-1] user=, db= LOG:  consistent recovery
state reached at B/C0D3B030
2017-01-06 13:06:46 BRST [1227]: [3-1] user=, db= LOG:  database system is
ready to accept read only connections
2017-01-06 13:06:46 BRST [1883]: [6-1] user=, db= LOG:  record with
incorrect prev-link B/BBD4FF30 at B/C0D4FF78
2017-01-06 13:06:46 BRST [2132]: [1-1] user=, db= LOG:  started streaming
WAL from primary at B/C000 on timeline 1
2017-01-06 18:51:03 BRST [2132]: [2-1] user=, db= FATAL:  terminating
walreceiver due to timeout
2017-01-06 18:51:03 BRST [1883]: [7-1] user=, db= LOG:  record with zero
length at B/C1AE0F48
2017-01-06 18:51:18 BRST [2331]: [1-1] user=, db= LOG:  started streaming
WAL from primary at B/C100 on timeline 1
2017-01-06 18:52:18 BRST [2331]: [2-1] user=, db= FATAL:  terminating
walreceiver due to timeout
2017-01-06 18:52:33 BRST [2333]: [1-1] user=, db= LOG:  started streaming
WAL from primary at B/C100 on timeline 1
2017-01-06 18:53:33 BRST [2333]: [2-1] user=, db= FATAL:  terminating
walreceiver due to timeout
2017-01-06 18:53:48 BRST [2334]: [1-1] user=, db= LOG:  started streaming
WAL from primary at B/C100 on timeline 1
2017-01-06 18:54:48 BRST [2334]: [2-1] user=, db= FATAL:  terminating
walreceiver due to timeout
2017-01-06 18:55:03 BRST [2335]: [1-1] user=, db= LOG:  started streaming
WAL from primary at B/C100 on timeline 1

Tentei achar uma documentação sobre o assunto mais não foi possível.
Então:
1 - gostaria de saber se este erro implica em ter que refazer o standby
(slave)?
2 - os erros posteriores de timeout tem alguma coisa haver com esse erro?
3 - Existe uma forma de verificar a integridade do master/slave?

Verifiquei a quantidade de registros em várias tabelas e estes estavam
consistentes em ambos server's!


Uso linux nos dois server's: CentOS Linux release 7.1.1503 (Core);
Postgresql Versão 9.4.10 no master e slave

Agradecimentos antecipados.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] TCP_KEEPALIVE - OPÇÃO NÃO SUPORTADA PELO PROTOCOLO

[MIGUEL JOSE DE LIMA]

>> Por algum motivo a Oracle mudou o nome da opção TCP_KEEPALIVE ou não
>> suporta lê-la? Isso já foi reportado na lista -bugs [1] mas ninguém se
>> importou em corrigir ainda. Isso não é algo preocupante a não ser o fato
>> de encher o seu log com essas mensagens. Por curiosidade, o postgres foi
>> compilado na própria máquina ou você instalou algum pacote?

Foi compilado na própria máquina.

Obrigado, sendo assim fico mais tranquilo que não é um erro mais grave.

Em 2 de setembro de 2016 19:15, Euler Taveira <eu...@timbira.com.br>
escreveu:

> On 02-09-2016 18:24, MIGUEL JOSE DE LIMA wrote:
> > LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
> >
> Por algum motivo a Oracle mudou o nome da opção TCP_KEEPALIVE ou não
> suporta lê-la? Isso já foi reportado na lista -bugs [1] mas ninguém se
> importou em corrigir ainda. Isso não é algo preocupante a não ser o fato
> de encher o seu log com essas mensagens. Por curiosidade, o postgres foi
> compilado na própria máquina ou você instalou algum pacote?
>
> Os parâmetros no PostgreSQL não vão fazer diferença se no sistema
> operacional eles não puderem ser aplicados.
>
>
> [1]
> https://www.postgresql.org/message-id/CAJgtxT6QL0_Gt+
> TkSDw=q1=yvjkt73fosrtstcu5hy+-sxn...@mail.gmail.com
>
>
> --
>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
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] TCP_KEEPALIVE - OPÇÃO NÃO SUPORTADA PELO PROTOCOLO

[MIGUEL JOSE DE LIMA]

2016-09-02 18:44 GMT-03:00 Flavio Henrique Araque Gurgel <fha...@gmail.com>:

>
>
> Em sex, 2 de set de 2016 23:24, MIGUEL JOSE DE LIMA <
> mig...@inlocsistemas.com.br> escreveu:
>
>> Alguém sabe me dizer porque recebo erro no log do server fazendo
>> referência ao TCP_KEEPALIVE:
>> LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
>>
>> Trabalho com SPARC SOLARIS 10 e Postgresql 9.5.4 (64bits)
>>
>> Parte do log do server:
>> 
>> 
>> --
>>
>> ERROR:  syntax error at end of input at character 184
>> STATEMENT:  SELECT "pon_unidade_supervisao".*, "cor_unidade".*
>> FROM "pon_unidade_supervisao"
>> INNER JOIN "corporativo"."cor_unidade" ON "unu_id_unidade" =
>> "uni_id_unidade"
>> WHERE "unu_id_pessoa" =
>> WARNING:  there is no transaction in progress
>> LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
>> STATEMENT:  SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
>> 'track_counts')
>> ERROR:  permission denied for relation pon_configuracao
>> STATEMENT:  SELECT count(*) AS rows FROM ONLY ponto.pon_configuracao
>> LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
>> STATEMENT:  SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
>> 'track_counts')
>> 
>> 
>> 
>>
>> Obs.: O parâmetros de TCP_... no postgresql.conf estão no padrão default!
>>  # - TCP Keepalives -
>>  #tcp_keepalives_idle = 0# TCP_KEEPIDLE, in
>> seconds;
>>  #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in
>> seconds;
>>  #tcp_keepalives_count = 0   # TCP_KEEPCNT;
>>
>>
>> Obrigado.
>>
>
> >>Solaris 10 não suporta keepalives.
> >>Por algum motivo, foi setado no seu servidor, verifique scripts de
> inicialização e se está olhando o bom conf.
>

Gurgel obrigado,
mas sinceramente não entendi o q vc quis dizer com "...está olhando o bom
conf" rsrsrs.
O postgresql.conf está com as configurações padrões como citei acima.
Não estou entendendo, tem alguma configuração no S.O do server?
Conforme está no manual (18.3.1), deveria ser zero, como está, para
sistemas que não suportam keepalive.

Grato.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] TCP_KEEPALIVE - OPÇÃO NÃO SUPORTADA PELO PROTOCOLO

[MIGUEL JOSE DE LIMA]

Alguém sabe me dizer porque recebo erro no log do server fazendo referência
ao TCP_KEEPALIVE:
LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol

Trabalho com SPARC SOLARIS 10 e Postgresql 9.5.4 (64bits)

Parte do log do server:
--

ERROR:  syntax error at end of input at character 184
STATEMENT:  SELECT "pon_unidade_supervisao".*, "cor_unidade".*
FROM "pon_unidade_supervisao"
INNER JOIN "corporativo"."cor_unidade" ON "unu_id_unidade" =
"uni_id_unidade"
WHERE "unu_id_pessoa" =
WARNING:  there is no transaction in progress
LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
STATEMENT:  SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
'track_counts')
ERROR:  permission denied for relation pon_configuracao
STATEMENT:  SELECT count(*) AS rows FROM ONLY ponto.pon_configuracao
LOG:  getsockopt(TCP_KEEPALIVE) failed: Option not supported by protocol
STATEMENT:  SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
'track_counts')


Obs.: O parâmetros de TCP_... no postgresql.conf estão no padrão default!
 # - TCP Keepalives -
 #tcp_keepalives_idle = 0# TCP_KEEPIDLE, in seconds;
 #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in
seconds;
 #tcp_keepalives_count = 0   # TCP_KEEPCNT;


Obrigado.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] SPARC SOLARIS - Postgresql 32bits ou 64bits

[MIGUEL JOSE DE LIMA]

Pessoal,

Pretendo instalar o Postgresql 9.5.4 em um server SUN SPARC T5 e SUN SPARC
T7 ambos com SOLARIS 10 e mais de 500GB de ran

Não sou da área de S.O., mas como vou trabalhar em ambiente de 64bits,
creio o Postgresql deveria ser de 64 bits. Certo?
Na literatura do Postgresql (Cap. 15, 15.7.6.5) diz:
 "If you do not have a reason to use 64-bit binaries on SPARC, prefer the
32-bit version. The 64-bit operations are slower and 64-bit binaries are
slower than the 32-bit variants. And on other hand, 32-bit code on the
AMD64 CPU family is not native, and that is why 32-bit code is significant
slower on this CPU family."

Portanto a dúvida: devo usar 64 ou 32bits.

Se puderem me ajudar ou indicar uma leitura fico agradecido.

Miguel José de Lima
___
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

[MIGUEL JOSE DE LIMA]

  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

[pgbr-geral] INSERT AGUARDANDO TRANSAÇÃO (VIOLAÇÃO DE CHAVE)

[MIGUEL JOSE DE LIMA]

Bom Dia,

Se possível, como posso interromper (obter erro/status) para um INSERT
(que viola chave) não fique aguardando outra transação em aberto?
Li sobre pg_am aminsert, mas não sei se é por ai!??? Se é como aplicar?

Obrigado.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] INSERT AGUARDANDO TRANSAÇÃO (VIOLAÇÃO DE CHAVE)

[MIGUEL JOSE DE LIMA]

Em 2 de abril de 2013 11:35, Dickson S. Guedes lis...@guedesoft.net escreveu:
 Em 2 de abril de 2013 10:41, MIGUEL JOSE DE LIMA
 mig...@inlocsistemas.com.br escreveu:
 Bom Dia,

 Se possível, como posso interromper (obter erro/status) para um INSERT
 (que viola chave) não fique aguardando outra transação em aberto?
 Li sobre pg_am aminsert, mas não sei se é por ai!??? Se é como aplicar?

 Se você deseja um controle sobre os bloqueios, você pode utilizar
 Bloqueios Explicitos [1] e pg_advisory_locks [2]. Triggers também
 podem te ajudar para determinadas situações.


 [1] http://www.postgresql.org/docs/current/static/explicit-locking.html
 [2] 
 http://www.postgresql.org/docs/current/static/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS

Não, não desejo um controle de bloqueio... Só não quero que uma SESSÃO
B  espere indefinidamente um tempo x para que a SESSÃO A termine
a transação. Desejo interromper a sessão 'B'...
Cenário:
Por coincidência a sessão 'B' deseja inserir e processar várias coisas
para um produto 'xx', que é o mesmo produto que a sessão 'A' iniciou a
transação.
No meu caso esta transação poderá demorar. então o desejo de
interromper a sessão 'B', para que esta mesma possa, tentar novamente
mais tarde ou fazer outra coisa, caso deseje.

Exemplo:
Uma função simples:
CREATE OR REPLACE FUNCTION regtb1() RETURNS int AS $$
DECLARE

BEGIN
BEGIN
INSERT INTO TB_1 VALUES (2, 124.654, 'REGISTRO SESSAO');
EXCEPTION   -- desejo interromper processamento e não aguardar
transação (não desejo aguardar o COMMIT de outra sessão/transação)
WHEN UNIQUE_VIOLATION THEN RAISE 'VIOLAÇÃO DE CHAVE - %', 
SQLSTATE;
WHEN OTHERS THEN RAISE 'ERRO STATUS - %', SQLSTATE;
END;
 -- varios outros processamentos...
 -- varios outros updates.
 -- etc...
   RETURN 1;
END;
$$
LANGUAGE PLPGSQL
=
SESSÃO 1:   |SESSÃO 2:
BEGIN WORK;  |   BEGING WORK;
SELECT regtb1()| SELECT regtb1() -- neste
momento interromper...'
--- Possível rollback;   |  ---
COMMIT;   |COMMIT;
===
É isso ai...
Obrigado.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] (sem assunto)

[MIGUEL JOSE DE LIMA]

Esse, tipo de problema, não tem receita de bolo.
Pode ser várias coisas, VACUUM, INDICES, MEMÓRIA etc.
Infelizmente não tenho como lhe ajudar assim. Mas cuidado com o vacc
umdb, pode demorar uma eternidade e estragar o banco, tem que leu muito
sobre isso. E faça backup para garantir.

Abraços. Estou de férias cara, escutando as ondas do mar e vendo a LUA
(mei lua ainda)...

- Miguel

Em 14 de março de 2011 21:50, Ratman Jr ratman...@hotmail.com escreveu:
 Boa noite

 Tenho um cliente que tem um banco de 70gb.
 Algumas vezes o servidor onde está o banco é reiniciado.
 Porém, sempre que o servidor é reiniciado a base volta rodando perfeita,
 rápida. Mas em 2 dias a velocidade cai muito, causando uma lentidão.

 A solução é executar o vacuumdb full, pois o analyze não resolve o problema.

 Alguém tem alguma idéia de como posso resolver esse problema?


 ___
 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

Re: [pgbr-geral] Fragmentação Horizontal e Vertica l

[MIGUEL JOSE DE LIMA]

Proveitando o Tópico...
Gostaria de perguntar, vale a pena usar no postgresql 9.0 herança para
fazer partiocionamento[1]? ou Herança de forma geral?
Esta pergunta é devido a algumas informações antigas que herança no
postgresql não era aconselhavel.
Obrigado

Em 19 de outubro de 2010 14:54, Leonardo Cezar lhce...@gmail.com escreveu:
 2010/10/18 Yuri Piratello yuri.pirate...@gmail.com:

 Estou começando a fuçar no Postgre e em alguns outros bancos a procura de
 Fragmentação em Tabelas.

 Qual resultado/objetivo vc espera em seu estudo ou fuçação sobre
 fragmentação de dados?

 - Voce poderia procurar por paralelismo de consultas e falar em fragmentação;
 - Voce poderia falar em isolamento de dados ( ACID) e ainda assim
 tratar com fragmentação;
 - Replicação ou balanceamento de carga tambem podem se desfrutar de
 fragmentação;
 - Voce poderia ainda falar de mineração de dados ou /data warehousing/
 e resolver com fragmentação e por ai vai ...

 No artigo [4], obtido a partir de acm.org, voce poderá verificar
 benefícios e os problemas com fragmentação horizontal de dados dentro
 de um /data-grid/.

 O conceito vem banco de dados distribuído.
 Porém eu gostaria de colocar em uma base centralizada.

 Voce poderia se beneficiar de particionamento[1] e alcançar a tal
 fragmentação também ...

 CREATE TABLE horas_trabalhadas(
   id_empregado INTEGER
   ,dt_registro DATE
 );

 CREATE TABLE horas_trabalhadas_julho(
   CHECK dt_registro BETWEEN '2010/07/01' AND '2010/07/31'
 ) INHERITS (horas_trabalhadas);

 Pesquisei e encontrei dois softwares: pgCluster e Slony.
 O pgCluster encontrei que faz a fragmentação dividindo a tabela em fragmento
 de acordo com a condição WHERE.

 Ambos não servem para particionamento/fragmentação:
 - PgCluster é uma ferramenta de replicação síncrona muti-master e
 AFAIK descontinuado.
 - Slony é uma ferramenta de replicação assíncrona master com múltiplos slaves;

 Veja a ferramenta PLProxy[3] para isto

 Ex:

 /*definição e alocação dos fragmentos dos produtos*/

 sc=# CREATE FRAGMENT PRODUTO_FLN ON PRODUTO WHERE ID_CIDADE_ORIGEM=1;
 sc=# PLACE PRODUTO_FLN ON FLN;
 sc=# CREATE FRAGMENT PRODUTO_JVL ON PRODUTO WHERE ID_CIDADE_ORIGEM=2;
 sc=# PLACE PRODUTO_JVL ON JVL;

 Não é nada disto! O pg_cluster não sabe absolutamente nada sobre
 particionamento de dados!! Pg_grid é uma extensão proposta pelo autor
 no link *original*[2]  e até onde entendi, não passa de um artigo.

 Fonte:
  http://kambing.ui.ac.id/postgresql/projects/pgFoundry/pggrid/artigo.pdf

 O link correto de origem é [2]

 1) http://www.postgresql.org/docs/9.0/interactive/ddl-partitioning.html
 2) http://pgfoundry.org/projects/pggrid/
 3) http://plproxy.projects.postgresql.org/doc/tutorial.html
 4) http://is.gd/g8nxa

 Abraço!

 -Leo
 --
 Leonardo Cezar
 http://www.aslid.org.br
 http://postgreslogia.wordpress.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

[pgbr-geral] Segmentos de WAL

[MIGUEL JOSE DE LIMA]

Pessoal,
Já tentei mas não consigo enteder a lógica geração dos arquivos de WAL.
No meu caso eu ativei os o WAL, e já existia várias sequencias, mas o
que não consigo entender
porque existe várias sequencias além da que esta sendo
atualizada(00010023)
no momento atual.
veja:
srvsas:/../postgresql843/pgsql/data/pg_xlog# ls -laht 0*
-rw--- 1 postgres postgres 16M Out  1 11:03 00010023
-rw--- 1 postgres postgres 254 Out  1 10:01
00010022.0020.backup
-rw--- 1 postgres postgres 16M Out  1 10:01 0001002A
-rw--- 1 postgres postgres 16M Out  1 09:58 00010029
-rw--- 1 postgres postgres 16M Set 29 08:16 00010028
-rw--- 1 postgres postgres 16M Set 29 08:14 00010027
-rw--- 1 postgres postgres 16M Set 28 17:30 00010026
-rw--- 1 postgres postgres 16M Set 24 08:08 00010025
-rw--- 1 postgres postgres 16M Set 24 08:01 00010024
srvsas:/u1/postgresql843/pgsql/data/pg_xlog# ls -laht 0*
-rw--- 1 postgres postgres 16M Out  1 11:08 00010023
-rw--- 1 postgres postgres 254 Out  1 10:01
00010022.0020.backup
-rw--- 1 postgres postgres 16M Out  1 10:01 0001002A
-rw--- 1 postgres postgres 16M Out  1 09:58 00010029
-rw--- 1 postgres postgres 16M Set 29 08:16 00010028
-rw--- 1 postgres postgres 16M Set 29 08:14 00010027
-rw--- 1 postgres postgres 16M Set 28 17:30 00010026
-rw--- 1 postgres postgres 16M Set 24 08:08 00010025
-rw--- 1 postgres postgres 16M Set 24 08:01 00010024

Por que existem as sequencias ...0024 até ...002A? Sendo que a
atualização atual é na ...0023.
Esta dúvida é maior ainda, poque se eu fizer um novo backup on-line a
sequencia ...0024
que foi gerado no dia 24 de sentembro é a que séra definida como ponto
de partida para
este novo backup.

Se puderem me esclarecer fico agradecido.
Eu uso linux DEBIAN 5.04 e postgreSQL 8.4.3

Muito Obrigado
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Teste

[MIGUEL JOSE DE LIMA]

Teste - Se email esta sendo enviado
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Segmentos de WAL

[MIGUEL JOSE DE LIMA]

Pessoal,
Já tentei mas não consigo enteder a lógica geração dos arquivos de WAL.
No meu caso eu ativei os o WAL, e já existia várias sequencias, mas o que
não consigo entender
porque existe várias sequencias além da que esta sendo
atualizada(00010023)
no momento atual.
veja:
srvsas:/../postgresql843/pgsql/data/pg_xlog# ls -laht 0*
-rw--- 1 postgres postgres 16M Out  1 11:03 00010023
-rw--- 1 postgres postgres 254 Out  1 10:01
00010022.0020.backup
-rw--- 1 postgres postgres 16M Out  1 10:01 0001002A
-rw--- 1 postgres postgres 16M Out  1 09:58 00010029
-rw--- 1 postgres postgres 16M Set 29 08:16 00010028
-rw--- 1 postgres postgres 16M Set 29 08:14 00010027
-rw--- 1 postgres postgres 16M Set 28 17:30 00010026
-rw--- 1 postgres postgres 16M Set 24 08:08 00010025
-rw--- 1 postgres postgres 16M Set 24 08:01 00010024
srvsas:/u1/postgresql843/pgsql/data/pg_xlog# ls -laht 0*
-rw--- 1 postgres postgres 16M Out  1 11:08 00010023
-rw--- 1 postgres postgres 254 Out  1 10:01
00010022.0020.backup
-rw--- 1 postgres postgres 16M Out  1 10:01 0001002A
-rw--- 1 postgres postgres 16M Out  1 09:58 00010029
-rw--- 1 postgres postgres 16M Set 29 08:16 00010028
-rw--- 1 postgres postgres 16M Set 29 08:14 00010027
-rw--- 1 postgres postgres 16M Set 28 17:30 00010026
-rw--- 1 postgres postgres 16M Set 24 08:08 00010025
-rw--- 1 postgres postgres 16M Set 24 08:01 00010024

Por que existem as sequencias ...0024 até ...002A? Sendo que a atualização
atual é na ...0023.
Esta dúvida é maior ainda, poque se eu fizer um novo backup on-line a
sequencia ...0024
que foi gerado no dia 24 de sentembro é a que séra definida como ponto de
partida para
este novo backup.

Se puderem me esclarecer fico agradecido.
Eu uso linux DEBIAN 5.04 e postgreSQL 8.4.3

Muito Obrigado
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Fwd: Aquivos (segmetos) de WAL

[MIGUEL JOSE DE LIMA]

Pessoal,
Já tentei mas não consigo enteder a lógica geração dos arquivos de WAL.
No meu caso eu ativei os o WAL, e já existia várias sequencias, mas o que
não consigo entender
porque existe várias sequencias além da que esta sendo
atualizada(00010023)
no momento atual.
veja:
srvsas:/../postgresql843/pgsql/data/pg_xlog# ls -laht 0*
*-rw--- 1 postgres postgres 16M Out  1 11:03 00010023  *
-rw--- 1 postgres postgres 254 Out  1 10:01
00010022.0020.backup
-rw--- 1 postgres postgres 16M Out  1 10:01 0001002A
-rw--- 1 postgres postgres 16M Out  1 09:58 00010029
-rw--- 1 postgres postgres 16M Set 29 08:16 00010028
-rw--- 1 postgres postgres 16M Set 29 08:14 00010027
-rw--- 1 postgres postgres 16M Set 28 17:30 00010026
-rw--- 1 postgres postgres 16M Set 24 08:08 00010025
-rw--- 1 postgres postgres 16M Set 24 08:01 00010024
srvsas:/../postgresql843/pgsql/data/pg_xlog# ls -laht 0*
-rw--- 1 postgres postgres 16M Out  1 11:08 00010023
-rw--- 1 postgres postgres 254 Out  1 10:01
00010022.0020.backup
-rw--- 1 postgres postgres 16M Out  1 10:01 0001002A
-rw--- 1 postgres postgres 16M Out  1 09:58 00010029
-rw--- 1 postgres postgres 16M Set 29 08:16 00010028
-rw--- 1 postgres postgres 16M Set 29 08:14 00010027
-rw--- 1 postgres postgres 16M Set 28 17:30 00010026
-rw--- 1 postgres postgres 16M Set 24 08:08 00010025
-rw--- 1 postgres postgres 16M Set 24 08:01 00010024

Por que existem as sequencias ...0024 até ...002A? Sendo que a atualização
atual é na ...0023.
Esta dúvida é maior ainda, poque se eu fizer um novo backup on-line a
sequencia ...0024
que foi gerado no dia 24 de sentembro é a que séra definida como ponto de
partida para
este novo backup.

Se puderem me esclarecer fico agradecido.
Eu uso linux DEBIAN 5.04 e postgreSQL 8.4.3

Muito Obrigado.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Aquivos (segmetos) de WAL

[MIGUEL JOSE DE LIMA]

Pessoal,
Já tentei mas não consigo enteder a lógica geração dos arquivos de WAL.
No meu caso eu ativei os o WAL, e já existia várias sequencias, mas o que
não consigo entender
porque existe várias sequencias além da que esta sendo
atualizada(00010023)
no momento atual.
veja:
srvsas:/../postgresql843/pgsql/data/pg_xlog# ls -laht 0*
*-rw--- 1 postgres postgres 16M Out  1 11:03 00010023  *
-rw--- 1 postgres postgres 254 Out  1 10:01
00010022.0020.backup
-rw--- 1 postgres postgres 16M Out  1 10:01 0001002A
-rw--- 1 postgres postgres 16M Out  1 09:58 00010029
-rw--- 1 postgres postgres 16M Set 29 08:16 00010028
-rw--- 1 postgres postgres 16M Set 29 08:14 00010027
-rw--- 1 postgres postgres 16M Set 28 17:30 00010026
-rw--- 1 postgres postgres 16M Set 24 08:08 00010025
-rw--- 1 postgres postgres 16M Set 24 08:01 00010024
srvsas:/u1/postgresql843/pgsql/data/pg_xlog# ls -laht 0*
-rw--- 1 postgres postgres 16M Out  1 11:08 00010023
-rw--- 1 postgres postgres 254 Out  1 10:01
00010022.0020.backup
-rw--- 1 postgres postgres 16M Out  1 10:01 0001002A
-rw--- 1 postgres postgres 16M Out  1 09:58 00010029
-rw--- 1 postgres postgres 16M Set 29 08:16 00010028
-rw--- 1 postgres postgres 16M Set 29 08:14 00010027
-rw--- 1 postgres postgres 16M Set 28 17:30 00010026
-rw--- 1 postgres postgres 16M Set 24 08:08 00010025
-rw--- 1 postgres postgres 16M Set 24 08:01 00010024

Por que existem as sequencias ...0024 até ...002A? Sendo que a atualização
atual é na ...0023.
Esta dúvida é maior ainda, poque se eu fizer um novo backup on-line a
sequencia ...0024
que foi gerado no dia 24 de sentembro é a que séra definida como ponto de
partida para
este novo backup.

Se puderem me esclarecer fico agradecido.
Eu uso linux DEBIAN 5.04 e postgreSQL 8.4.3

Muito Obrigado
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Postgres + out of memory

[MIGUEL JOSE DE LIMA]

Se seu ambiente for linux/unix veja o tamanho do seu SHMMAX do kernel:
ex.: kernel.shmmax = 4014833664

-

2010/9/15 gilmarli...@agrovale.com.br

 Olá!
 Talvez alguem na lista poderá me da uma dica, esta acontecendo no meu
 servidor postgres, a seguinte mensagem
 Um erro ocorreu:


 ERROR:  out of memory
 DETALHE:  Failed on request of size 196608

 Este problema começou a ocorrer a 1 mes com uma frequencia 2 veses na
 semana.
 Este servidor possui 8 GB de memoria, o postgres esta setado para trabalhar
 com 400 conexões
 simultaneas, no memento que da esta mensagem, consegui pegar que tinha 290
 conexões.
 Ainda faltava muito para alcançar o limite.
 Segue abaixo o postgres.conf que estou usando.


 #--
 # CONNECTIONS AND AUTHENTICATION

 #--

 # - Connection Settings -

 listen_addresses = '*'# what IP address(es) to listen on;
 # comma-separated list of addresses;
 # defaults to 'localhost', '*' = all
 # (change requires restart)
 *port = 5573# (change requires restart)*
 *max_connections = 400# (change requires restart)*
 # Note:  Increasing max_connections costs ~400 bytes of shared memory per
 # connection slot, plus lock space (see max_locks_per_transaction).
 #superuser_reserved_connections = 3# (change requires restart)
 #unix_socket_directory = ''# (change requires restart)
 #unix_socket_group = ''# (change requires restart)
 #unix_socket_permissions = 0777# begin with 0 to use octal notation
 # (change requires restart)
 #bonjour_name = ''# defaults to the computer name
 # (change requires restart)

 # - Security and Authentication -

 #authentication_timeout = 1min# 1s-600s
 #ssl = off# (change requires restart)
 #ssl_ciphers = 'ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH'# allowed SSL
 ciphers
 # (change requires restart)
 #ssl_renegotiation_limit = 512MB# amount of data between renegotiations
 #password_encryption = on
 #db_user_namespace = off

 # Kerberos and GSSAPI
 #krb_server_keyfile = ''
 #krb_srvname = 'postgres'# (Kerberos only)
 #krb_caseins_users = off

 # - TCP Keepalives -
 # see man 7 tcp for details

 #tcp_keepalives_idle = 0# TCP_KEEPIDLE, in seconds;
 # 0 selects the system default
 #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in seconds;
 # 0 selects the system default
 #tcp_keepalives_count = 0# TCP_KEEPCNT;
 # 0 selects the system default



 #--
 # RESOURCE USAGE (except WAL)

 #--

 # - Memory -

 #shared_buffers = 32MB# min 128kB
 *shared_buffers = 2816MB# pgtune wizard 2010-06-07*

 # (change requires restart)
 #temp_buffers = 8MB# min 800kB
 #max_prepared_transactions = 0# zero disables the feature
 # (change requires restart)
 # Note:  Increasing max_prepared_transactions costs ~600 bytes of shared
 memory
 # per transaction slot, plus lock space (see max_locks_per_transaction).
 # It is not advisable to set max_prepared_transactions nonzero unless you
 # actively intend to use prepared transactions.
 #work_mem = 1MB# min 64kB
 *work_mem = 60MB# pgtune wizard 2010-06-07*


 #maintenance_work_mem = 16MB# min 1MB
 *maintenance_work_mem = 704MB# pgtune wizard 2010-06-07*

 #max_stack_depth = 2MB# min 100kB

 # - Kernel Resource Usage -

 #max_files_per_process = 1000# min 25
 # (change requires restart)
 #shared_preload_libraries = ''# (change requires restart)

 # - Cost-Based Vacuum Delay -

 #vacuum_cost_delay = 0ms# 0-100 milliseconds
 #vacuum_cost_page_hit = 1# 0-1 credits
 #vacuum_cost_page_miss = 10# 0-1 credits
 #vacuum_cost_page_dirty = 20# 0-1 credits
 #vacuum_cost_limit = 200# 1-1 credits

 # - Background Writer -

 #bgwriter_delay = 200ms# 10-1ms between rounds
 #bgwriter_lru_maxpages = 100# 0-1000 max buffers written/round
 #bgwriter_lru_multiplier = 2.0# 0-10.0 multipler on buffers
 scanned/round

 # - Asynchronous Behavior -

 #effective_io_concurrency = 1# 1-1000. 0 disables prefetching



 #--
 # WRITE AHEAD LOG

 #--

 # - Settings -

 #fsync = on# turns forced synchronization on or off
 

Re: [pgbr-geral] campo serial

[MIGUEL JOSE DE LIMA]

Creio que a documentação cita o início de sequencia veja o RESTART...

ALTER SEQUENCE *name* [ INCREMENT [ BY ] *increment* ]
[ MINVALUE *minvalue* | NO MINVALUE ] [ MAXVALUE *maxvalue* | NO MAXVALUE ]
[ RESTART [ WITH ] *start* ] [ CACHE *cache* ] [ [ NO ] CYCLE ]
[ OWNED BY { *table*.*column* | NONE } ]
ALTER SEQUENCE *name* SET SCHEMA *new_schema*



Em 29 de julho de 2010 21:42, Vinicius vinic...@totalsat.com.br escreveu:

  Desta forma eu sei,, mas quando eu crio uma nova tabela e coloco um campo
 do tipo serial, o postgres cria automaticamente o sequence com icremento by
 1,, gostaria de alterar este comportamento da auto criaçao do serial para
 ele criar automaticamente by 3.



 On 29/07/2010 09:29, Candido Vieira da Silva Neto wrote:

 ALTER SEQUENCE sequencia INCREMENT BY 3;

  http://www.postgresql.org/docs/8.2/static/sql-altersequence.html

 2010/7/29 Vinicius vinic...@totalsat.com.br

  Bom dia..

 Estou precisando que as sequences incrementem de 3 em 3, mas teria como
 ao utilizar o campo serial ele já criar a sequence com incremento de 3
 em 3 e nao 1 como é o default ?

 value...
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



 ___
 pgbr-geral mailing 
 listpgbr-ge...@listas.postgresql.org.brhttps://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



 --
 Vinicius D. Barba
 Totalsat - Departamento TI
 +55 41 2109-7716


 ___
 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

Re: [pgbr-geral] Campos-de-expressao no WHERE

[MIGUEL JOSE DE LIMA]

Fabrízio, Bom Dia!
Os seus exemplos foram de grande valia.
Mas, aproveitando a sua experiência, gostaria de perguntar mais uma coisa
(se possível a resposta.):
   A clausula HAVING tem custo significativo em relação a performace?
conforme
   o número de registros lidos!

Muito Obrigado.

2009/8/29 Fabrízio de Royes Mello fabriziome...@gmail.com

 2009/8/29 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br

 Pessoal,
 Em alguns produtos da M.S. eu podia usar o resultado de uma expressão na
 clausula WHERE e
 no PostgreSQL eu não consigo, dando erro que o campo não existe!
 Eu pergunto: É possível? Existe alguma referencia que possa ler?


 Miguel,

 O Oswaldo respondeu já respondeu que da forma que tu deseja não é possível,
 mas posso sugerir algumas alternativas??




 Ex.: SELECT c1, c2, COUNT(id) as qtde FROM tabela WHERE qtde  1
GROUP BY c1, c2 ...;
*** (erro qtde - não existe)



 No primeiro exemplo eu faria o seguinte:

 SELECT c1, c2, COUNT(id) as qtde FROM tabela
 GROUP BY c1, c2 ...
 HAVING COUNT(id)  1;




 ou
SELECT c1,
  c2,
 (SELECT ... saldoanterior FROM tbsaldo... WHERE ano =
 '2008') AS c3,
 CASE c3 ... AS c4 ... FROM tabela;
 *** Neste caso eu gostaria de testar SE o RESULTADO DE c3 É NULO
  (pode não existir dados p/ saldo anterior) e criar o campo c4
 com um CASE.
   ou seja, se c3 IS NULL retorna 0.000 se não retorna c3.
  ---


 E no segundo exemplo eu utilizaria uma sub-query para fazer o que você
 precisa, mais ou menos assim:

 SELECT a.*,
   COALESCE(a.c3, 0) AS c4
 FROM (
SELECT c1,
  c2,
  (SELECT ... saldoanterior FROM tbsaldo... WHERE ano =
 '2008') AS c3
FROM tabela
 ) AS a ;

 Espero ter ajudado.

 Cordialmente,

 --
 Fabrízio de Royes Mello
  Blog sobre TI: http://fabriziomello.blogspot.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

[pgbr-geral] Campos-de-expressao no WHERE

[MIGUEL JOSE DE LIMA]

Pessoal,
Em alguns produtos da M.S. eu podia usar o resultado de uma expressão na
clausula WHERE e
no PostgreSQL eu não consigo, dando erro que o campo não existe!
Eu pergunto: É possível? Existe alguma referencia que possa ler?

Ex.: SELECT c1, c2, COUNT(id) as qtde FROM tabela WHERE qtde  1
   GROUP BY c1, c2 ...;
   *** (erro qtde - não existe)
ou
   SELECT c1,
 c2,
(SELECT ... saldoanterior FROM tbsaldo... WHERE ano =
'2008') AS c3,
CASE c3 ... AS c4 ... FROM tabela;
*** Neste caso eu gostaria de testar SE o RESULTADO DE c3 É NULO
 (pode não existir dados p/ saldo anterior) e criar o campo c4
com um CASE.
  ou seja, se c3 IS NULL retorna 0.000 se não retorna c3.
 ---
O intuito não é discutir lógica ou necessidade, é saber se é possível?

Muito Obrigado!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] INSERT - Ignorar Chave Duplicada

[MIGUEL JOSE DE LIMA]

Pessoal,
Em um procedimento para inserir várias linhas/registros (INSERT ... SELECT
) como
posso contornar o erro de chave duplicada, sem interromper o
processamento???

Pesquisei na lista e não achei nada. E através do google achei um exemplo
que utiliza uma SubQuery
com a clausula NOT IN (SELECT ...). Será que esta é a melhor forma?
Não existe nada parecido com o INSERT IGNORE ... do MySQL? (Postgresql 8.3
ou 8.4)

Obrigado.

---Miguel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] INSERT - Ignorar Chave Duplicada

[MIGUEL JOSE DE LIMA]

Caro colega, talvez eu não expliquei direito: Eu não desejo registros
duplicados!!!
Então, não basta deletar a constraint. E por outro lado eu não tenho
conhecimento suficiente para afirmar que há uma aberração em outro produto,
mas tenho conhecimento suficiente para dizer que em muitos processamentos a
INSERSSÃO DE REGISTROS ignorando os erros de duplicidades é muito mais
rapido, sem ter a necessidade de
verificar a duplicidade da chave e inclusive a do registro!

Mas valeu, Muito Obrigado

2009/8/20 Roberto Mello roberto.me...@gmail.com

 2009/8/20 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br:
   Pessoal,
  Em um procedimento para inserir várias linhas/registros (INSERT ...
 SELECT
  ) como
  posso contornar o erro de chave duplicada, sem interromper o
  processamento???
 
  Pesquisei na lista e não achei nada. E através do google achei um exemplo
  que utiliza uma SubQuery
  com a clausula NOT IN (SELECT ...). Será que esta é a melhor forma?
  Não existe nada parecido com o INSERT IGNORE ... do MySQL? (Postgresql
 8.3
   ou 8.4)

 Não. Esse tipo de aberração grotesca só se vê num produto como o MySQL.

 Se quiser o mesmo efeito no PostgreSQL, faça um DROP na constraint,
 faça suas inserções, e depois re-crie a chave ou constraint.

 Roberto
 ___
 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

Re: [pgbr-geral] INSERT - Ignorar Chave Duplicada

[MIGUEL JOSE DE LIMA]

Oi André, tento estudar o máximo possível antes de fazer alguma pergunta ao
grupo,
mas confesso que sou totalmente inexperiente no postgresql, ou seja,
confesso que
estou tendo dificuldades em entender o seu exemplo:
Quando há uma violação, conforme o seu exemplo, o processamento irá
continuar?
e as mensagem de violação, como fasso para ignora-las ou invia-las para um
lixo
temporário?
Se puder continuar me ajudando, fico agradecido!

Valeu!

2009/8/20 Andre Fernandes fernandes.an...@gmail.com

 Como disse antes, podes usar uma trigger para ignorar registros duplicados
 durante a inserção, dessa forma se o registro já existir na base de dados, a
 trigger ignoraria esse comando. Dessa forma, não terias problemas de
 duplicidade alguma.

 Abraços,
 André.

   2009/8/20 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br

 Caro colega, talvez eu não expliquei direito: Eu não desejo registros
 duplicados!!!
 Então, não basta deletar a constraint. E por outro lado eu não tenho
 conhecimento suficiente para afirmar que há uma aberração em outro produto,
 mas tenho conhecimento suficiente para dizer que em muitos processamentos a
 INSERSSÃO DE REGISTROS ignorando os erros de duplicidades é muito mais
 rapido, sem ter a necessidade de
 verificar a duplicidade da chave e inclusive a do registro!

 Mas valeu, Muito Obrigado

  2009/8/20 Roberto Mello roberto.me...@gmail.com

 2009/8/20 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br:

   Pessoal,
  Em um procedimento para inserir várias linhas/registros (INSERT ...
 SELECT
  ) como
  posso contornar o erro de chave duplicada, sem interromper o
  processamento???
 
  Pesquisei na lista e não achei nada. E através do google achei um
 exemplo
  que utiliza uma SubQuery
  com a clausula NOT IN (SELECT ...). Será que esta é a melhor forma?
  Não existe nada parecido com o INSERT IGNORE ... do MySQL?
 (Postgresql 8.3
   ou 8.4)

 Não. Esse tipo de aberração grotesca só se vê num produto como o MySQL.

 Se quiser o mesmo efeito no PostgreSQL, faça um DROP na constraint,
 faça suas inserções, e depois re-crie a chave ou constraint.

 Roberto
 ___
 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




 --
 André de Camargo Fernandes



 ___
 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

Re: [pgbr-geral] INSERT - Ignorar Chave Duplicada

[MIGUEL JOSE DE LIMA]

OK, Valeu!


2009/8/20 André Volpato andre.volp...@ecomtecnologia.com.br

 MIGUEL JOSE DE LIMA escreveu:
  Oi André, tento estudar o máximo possível antes de fazer alguma
  pergunta ao grupo,
  mas confesso que sou totalmente inexperiente no postgresql, ou seja,
  confesso que
  estou tendo dificuldades em entender o seu exemplo:
  Quando há uma violação, conforme o seu exemplo, o processamento irá
  continuar?

 Sim, o processamento irá continuar.
 O lado ruim é que PLs com EXCEPTION são um pouco mais custosas, mas
 nesse caso são indispensáveis.


  e as mensagem de violação, como fasso para ignora-las ou invia-las
  para um lixo
  temporário?

 Para ignorar completamente:

 BEGIN
INSERT...
 EXCEPTION WHEN unique_violation then null;
 END;

 --

 []´s, ACV


 ___
 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

Re: [pgbr-geral] INSERT - Ignorar Chave Duplicada

[MIGUEL JOSE DE LIMA]

Oi Tiago, para sua pergunta vou inserir apenas todos os registros que não
violaram a chave!
Mas de qualquer forma é uma alternativa.
Valeu, Obrigado!

2009/8/20 Tiago Adami adam...@gmail.com

 Olá, Miguel. Se entendi bem o seu problema você quer que o processo
 continue sendo executado, inserindo apenas o primeiro registro que possua a
 chave duplicada, certo? Ao invés de parar a execução gerando uma exceção,
 continuaria sendo executada inserindo os registros de outras chaves.

 Bem, para fazer isso, te dou duas alternativas:

 1) Remova os registros duplicados antes de inserí-los, OU

 2) Crie um arquivo com vários comandos INSERT delimitados por
 ponto-e-virgula e execute-o através do psql [1] via console (CMD no
 Windows). Assim quando houver um registro duplicado, ele apenas o avisará e
 continuará executando a próxima linha (desde que você não use o parâmetro
 -1 ou --single-transaction).

 A alternativa 1 deve ser utilizada se você estiver inserindo registros pela
 aplicação. A 2 apenas para carga de dados.

 [1] http://www.postgresql.org/docs/8.4/static/app-psql.html


 --
 Tiago J. Adami
 Dois Vizinhos - Paraná - Brasil



 2009/8/20 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br

 Oi André, tento estudar o máximo possível antes de fazer alguma pergunta
 ao grupo,
 mas confesso que sou totalmente inexperiente no postgresql, ou seja,
 confesso que
 estou tendo dificuldades em entender o seu exemplo:
 Quando há uma violação, conforme o seu exemplo, o processamento irá
 continuar?
 e as mensagem de violação, como fasso para ignora-las ou invia-las para um
 lixo
 temporário?
 Se puder continuar me ajudando, fico agradecido!

 Valeu!

 2009/8/20 Andre Fernandes fernandes.an...@gmail.com

  Como disse antes, podes usar uma trigger para ignorar registros
 duplicados durante a inserção, dessa forma se o registro já existir na base
 de dados, a trigger ignoraria esse comando. Dessa forma, não terias
 problemas de duplicidade alguma.

 Abraços,
 André.

   2009/8/20 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br

 Caro colega, talvez eu não expliquei direito: Eu não desejo registros
 duplicados!!!
 Então, não basta deletar a constraint. E por outro lado eu não tenho
 conhecimento suficiente para afirmar que há uma aberração em outro produto,
 mas tenho conhecimento suficiente para dizer que em muitos processamentos a
 INSERSSÃO DE REGISTROS ignorando os erros de duplicidades é muito mais
 rapido, sem ter a necessidade de
 verificar a duplicidade da chave e inclusive a do registro!

 Mas valeu, Muito Obrigado

  2009/8/20 Roberto Mello roberto.me...@gmail.com

 2009/8/20 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br:

   Pessoal,
  Em um procedimento para inserir várias linhas/registros (INSERT ...
 SELECT
  ) como
  posso contornar o erro de chave duplicada, sem interromper o
  processamento???
 
  Pesquisei na lista e não achei nada. E através do google achei um
 exemplo
  que utiliza uma SubQuery
  com a clausula NOT IN (SELECT ...). Será que esta é a melhor forma?
  Não existe nada parecido com o INSERT IGNORE ... do MySQL?
 (Postgresql 8.3
   ou 8.4)

 Não. Esse tipo de aberração grotesca só se vê num produto como o MySQL.

 Se quiser o mesmo efeito no PostgreSQL, faça um DROP na constraint,
 faça suas inserções, e depois re-crie a chave ou constraint.

 Roberto
 ___
 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




 --
 André de Camargo Fernandes



 ___
 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 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

Re: [pgbr-geral] BLOQUEIO DE REGISTRO

[MIGUEL JOSE DE LIMA]

Bom Dia!
Charly, me desculpe mas não consta um email seu anterior, mas pelo que vc
descreveu
agora, conicide com minha primeira postagem, ou seja, eu utilizei o LOCK ...
NOWAIT e
SELECT ... FOR UPDATE! Mas ficaria agradecido se vc enviasse o exemplo
novamente.
Obrigado!

2009/8/11 Charly Frankl carl...@gmail.com

 Miguel, boa noite...

 Para você bloquear os selects, faça todos com FOR UPDATE ... Ai você tem
 opções, onde para retornar logo que está ocupado utilize NOWAIT.

 Att,


 2009/8/11 JotaComm jota.c...@gmail.com

 Olá, Miguel

 Já comentei no email anterior e fiz uma pequena descrição de como isso
 funciona. Você deu uma olhada no exemplo que mandei?

 O PostgreSQL não bloqueia a leitura (SELECT), apenas operações de escrita
 (UPDATE e DELETE).


 2009/8/11 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br

 Oi Mário, Este é o problema a leitura nunca é bloqueada.
 Fiz os testes pedidos, mas para mim não mudou nada!
 Veja:
 - Na sessão 1:
  db_teste=# BEGIN WORK;
  BEGIN
  db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT;
  LOCK TABLE
  db_teste=# UPDATE tab_material SET desc_serma = 'LAPIS Y' where
 codg_serma='10';
  UPDATE 1
  db_teste=#   *** aguardando novo comando ***
 - Na sessão 2:
   db_teste=# BEGIN WORK;
   BEGIN
   db_teste=# SELECT * FROM tab_material where codg_serma='10';
   codg_empr | codg_serma |  id_serma  | desc_serma

---++++--+--
202   | 10 | 202010 | LAPIS Y|

 É isso ai!!!??
 Obrigado.

 2009/8/11 Mário Oshiro mario.osh...@gmail.com

 Em SQLServer, fiz um teste parecido com o seu.

 Qdo vc faz um lock de registro ou trabela,  ele nao bloqueia a leitura
 de outras sessoes, ate' que a
 sessao de posse do lock, faça um update de algum dado do registro.

 Para bloquear o select que vc fez, faca em seguida um update com a mesmo
 where assim :

  db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR UPDATE;
  update tab_material set codg_serma='10' where codg_serma='10' ;

 teste la e depois envie o resultado.

 até mais.



 MIGUEL JOSE DE LIMA wrote:
  Caros, participantes...
  Sou iniciante neste mundo do PostgreSQL.
  Trabalho com outro Banco de Dados - ADABAS (UNIX SOLARIS/MAINFRAME),
  mas me incubiram de fazer testes no PostgreSQL para bloquer registros.
  Então...
 
  Estou precisando de ajuda para bloquear a leitura de um registro, ou
  seja,
  em um cenário como:
   Atualização de Estoque de um Material :
  Antes de atualizar o estoque do material selecionado eu preciso
  bloquear o registro para que
  nenhuma outra sessão possa obter o dado do registro.
  PRECISO DE UMA LEITURA EXCLUSIVA - TOTALMENTE RESTRITIVA.
  Estou usando o PostgreSQL 8.3.7 para os testes - em linux
  Já li e reli sobre o Isolamento de Transação, mas pode ser que eu não
  esteja entendendo...???
  Fiz o seguinte teste via psql:
  - Na Sessão A
db_teste=# BEGIN WORK;
BEGIN
db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT;
LOCK TABLE
db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR
 UPDATE;
resultado obtido ok!
*** aqui eu preciso bloquear todos os materiais/itens (de um pedido)
  - como ex. fiz de apenas 1 (um).
 
  - Na Sessão B:
  ** Fiz o mesmo SELECT sem a clausula FOR UPDATE:
SELECT * FROM tab_material where codg_serma='10'
 
** aqui eu obtive o resultado ok da leitura.
   Portanto, é aqui, neste ponto que não deveria permitir nenhuma
  leitura, já que sessão A ainda não terminou!
   E AI ALGUÉM PODE ME AJUDAR!?
 
  Obrigado!
 
 
 
 
 
 
 
  ___
  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 mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



 []s
 --
 JotaComm
 http://jotacomm.wordpress.com
 http://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




 --
 Charly Frankl
 http://javadevilopers.blogspot.com/
 charlyfra...@gmail.com
 Linux user #391083

 ___
 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

Re: [pgbr-geral] BLOQUEIO DE REGISTRO

[MIGUEL JOSE DE LIMA]

Bom dia,
Leandro, eu concordo com vc, talvez tenho que aprender a conviver com os
conceitos
de Banco de Dados Relacional e SQL..., mas confesso a vc que para mim é meio

decepicionante, não conseguir LOCAR um registro para leitura e poder tratar
isso.
Até velho bom antigo CLIPPER fazia isso, vc imagina eu acostumado a fazer
isso
por logos anos, também com ADABAS.
Mas eu gostaria, se possível, de lhe perguntar: COMO É POSSÍVEL ATUALIZAR
UM SALDO DE QUALQUER COISA (estoque/contacorrente), SEM PRENDER O
REGISTRO PARA LEITURA? COMO POSSO SIMULAR ISSO?
Obs.: Como algumas pessoas já tentaram me ajudar..., informa mais uma vez
que
 o SELECT ... FOR UPDATE não bloquei leitura!

Obrigado!

2009/8/11 Leandro Henrique Pereira Neto 
leandro-henrique.pere...@serpro.gov.br

  Pelo que conheço não é uma questão do PostgreSQL e sim de bancos padrão
 SQL, pelo menos nos mais populares (SqlServer, Oracle, MySQL, PostgreSQL e
 DB2).

 O SELECT simples nunca é bloqueado (somente se usar for update).
 Porém usar todos os SQL com FOR UPDATE pode travar todo o seu sistema
 rapidinho já que somente uma transação poderá ler os dados de cada vez, como
 em sistema OLTP temos normalmente mais leitura do que alteração a coisa
 acaba ficando complicada.

 O que tem são os conceitos de transação e de consistência de leitura.

 Talvez seja o caso de você pensar o sistema em temos de bancos SQL e não
 tentar fazer no PostgreSQL o que um banco como o Adabas faz pois estruturas
 de funcionamento e implementação totalmente diferentes.

 Leandro Henrique Pereira Neto
 Administração de bancos de dados




 Charly Frankl escreveu:

 Miguel, boa noite...

 Para você bloquear os selects, faça todos com FOR UPDATE ... Ai você tem
 opções, onde para retornar logo que está ocupado utilize NOWAIT.

 Att,


 2009/8/11 JotaComm jota.c...@gmail.com

 Olá, Miguel

 Já comentei no email anterior e fiz uma pequena descrição de como isso
 funciona. Você deu uma olhada no exemplo que mandei?

 O PostgreSQL não bloqueia a leitura (SELECT), apenas operações de escrita
 (UPDATE e DELETE).


  2009/8/11 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br

 Oi Mário, Este é o problema a leitura nunca é bloqueada.
  Fiz os testes pedidos, mas para mim não mudou nada!
 Veja:
 - Na sessão 1:
   db_teste=# BEGIN WORK;
  BEGIN
  db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT;
  LOCK TABLE
   db_teste=# UPDATE tab_material SET desc_serma = 'LAPIS Y' where
 codg_serma='10';
  UPDATE 1
  db_teste=#   *** aguardando novo comando ***
  - Na sessão 2:
db_teste=# BEGIN WORK;
   BEGIN
db_teste=# SELECT * FROM tab_material where codg_serma='10';
   codg_empr | codg_serma |  id_serma  | desc_serma

---++++--+--
202   | 10 | 202010 | LAPIS Y|

 É isso ai!!!??
 Obrigado.

  2009/8/11 Mário Oshiro mario.osh...@gmail.com

 Em SQLServer, fiz um teste parecido com o seu.

 Qdo vc faz um lock de registro ou trabela,  ele nao bloqueia a leitura
 de outras sessoes, ate' que a
 sessao de posse do lock, faça um update de algum dado do registro.

 Para bloquear o select que vc fez, faca em seguida um update com a mesmo
 where assim :

  db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR UPDATE;
   update tab_material set codg_serma='10' where codg_serma='10' ;

 teste la e depois envie o resultado.

 até mais.



 MIGUEL JOSE DE LIMA wrote:
  Caros, participantes...
  Sou iniciante neste mundo do PostgreSQL.
  Trabalho com outro Banco de Dados - ADABAS (UNIX SOLARIS/MAINFRAME),
  mas me incubiram de fazer testes no PostgreSQL para bloquer registros.
  Então...
 
  Estou precisando de ajuda para bloquear a leitura de um registro, ou
  seja,
  em um cenário como:
   Atualização de Estoque de um Material :
  Antes de atualizar o estoque do material selecionado eu preciso
  bloquear o registro para que
  nenhuma outra sessão possa obter o dado do registro.
  PRECISO DE UMA LEITURA EXCLUSIVA - TOTALMENTE RESTRITIVA.
  Estou usando o PostgreSQL 8.3.7 para os testes - em linux
  Já li e reli sobre o Isolamento de Transação, mas pode ser que eu não
  esteja entendendo...???
  Fiz o seguinte teste via psql:
  - Na Sessão A
db_teste=# BEGIN WORK;
BEGIN
db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT;
LOCK TABLE
db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR
 UPDATE;
resultado obtido ok!
*** aqui eu preciso bloquear todos os materiais/itens (de um pedido)
  - como ex. fiz de apenas 1 (um).
 
  - Na Sessão B:
  ** Fiz o mesmo SELECT sem a clausula FOR UPDATE:
SELECT * FROM tab_material where codg_serma='10'
 
** aqui eu obtive o resultado ok da leitura.
   Portanto, é aqui, neste ponto que não deveria permitir nenhuma
  leitura, já que sessão A ainda não terminou!
   E AI ALGUÉM PODE ME AJUDAR!?
 
  Obrigado

Re: [pgbr-geral] BLOQUEIO DE REGISTRO

[MIGUEL JOSE DE LIMA]

OI, Charly,
Fiz os testes aqui, e é como vc passou. Realmente ajuda!
Valeu, Muito Obrigado!


2009/8/12 Charly Frankl carl...@gmail.com

 Bom dia Leandro...

 Concordo com você que seja um tanto quanto decepcionante você não
 conseguir um lock para consultas, mas como tratado, faz parte do modelo
 relacional. Também tive essa dificuldade no início, quando vim trabalhar com
 bancos relacionais.

 Bem, mas como comentei, uma forma de burlar esta restrição é utilizar a
 instrução FOR UPDATE NOWAIT. Segue um exemplo:

 Em uma seção do psql (pgadmin, aplicação da empresa, etc...) aberta eu
 realizo um select:

 begin;
 select *  from municipio where cod_uf = 43 FOR UPDATE NOWAIT;

 (Observe que eu não fechei a transação...)

 Se em outra seção aberta eu realizar o mesmo select :
 begin;
 select *  from municipio where cod_uf = 43 FOR UPDATE NOWAIT;

 O banco simplesmente me retorna a mensagem:
 ERROR:  could not obtain lock on row in relation municipio

 Bem... É uma forma de burlar o problema a princípio, mas como já discutido
 aqui, o melhor a fazer (ao menos a médio prazo) é rever a aplicação. Depois
 de revista, ai sim você pode optar pelo melhor modelo. Utilizar o FOR UPDATE
 NOWAIT em consultas de atualização não é um erro, mas utilizá-lo
 indiscriminadamente pode trazer transtornos e efeitos colaterais não
 desejados. Todavia, como cada caso exige uma solução específica, fica ai a
 sugestão.


 Espero ter ajudado.

 Att,



 --
 Charly Frankl
 http://javadevilopers.blogspot.com/
 charlyfra...@gmail.com
 Linux user #391083





 2009/8/12 JotaComm jota.c...@gmail.com

 Olá, Miguel

 Faça o seguinte:

 Sessão A:
 BEGIN;
 UPDATE tabela SET codigo=100 WHERE codigo=1;
 --Vá para a sessão B


 Sessão B:
 BEGIN; --Opcional
 SELECT * FROM tabela WHERE codigo=1;
 --Aqui você ainda verá o registro 1, porque a transação (Sessão A) que
 está alterando o registro não fez o commit, então consequentemente você não
 consegue através desta sessão ver que o registro foi modificado. Para ver
 que o registro 1 não existe mais é necessário executar o comando COMMIT na
 Sessão A.

 Qualquer dúvida pergunta ai.

 2009/8/12 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br

 Bom dia,
 Leandro, eu concordo com vc, talvez tenho que aprender a conviver com os
 conceitos
 de Banco de Dados Relacional e SQL..., mas confesso a vc que para mim é
 meio
 decepicionante, não conseguir LOCAR um registro para leitura e poder
 tratar isso.
 Até velho bom antigo CLIPPER fazia isso, vc imagina eu acostumado a fazer
 isso
 por logos anos, também com ADABAS.
 Mas eu gostaria, se possível, de lhe perguntar: COMO É POSSÍVEL ATUALIZAR

 UM SALDO DE QUALQUER COISA (estoque/contacorrente), SEM PRENDER O
 REGISTRO PARA LEITURA? COMO POSSO SIMULAR ISSO?
 Obs.: Como algumas pessoas já tentaram me ajudar..., informa mais uma vez
 que
  o SELECT ... FOR UPDATE não bloquei leitura!

 Obrigado!

  2009/8/11 Leandro Henrique Pereira Neto 
 leandro-henrique.pere...@serpro.gov.br

  Pelo que conheço não é uma questão do PostgreSQL e sim de bancos padrão
 SQL, pelo menos nos mais populares (SqlServer, Oracle, MySQL, PostgreSQL e
 DB2).


 O SELECT simples nunca é bloqueado (somente se usar for update).
 Porém usar todos os SQL com FOR UPDATE pode travar todo o seu sistema
 rapidinho já que somente uma transação poderá ler os dados de cada vez, 
 como
 em sistema OLTP temos normalmente mais leitura do que alteração a coisa
 acaba ficando complicada.

 O que tem são os conceitos de transação e de consistência de leitura.

 Talvez seja o caso de você pensar o sistema em temos de bancos SQL e não
 tentar fazer no PostgreSQL o que um banco como o Adabas faz pois estruturas
 de funcionamento e implementação totalmente diferentes.

 Leandro Henrique Pereira Neto
 Administração de bancos de dados




 Charly Frankl escreveu:

 Miguel, boa noite...

 Para você bloquear os selects, faça todos com FOR UPDATE ... Ai você tem
 opções, onde para retornar logo que está ocupado utilize NOWAIT.

 Att,


 2009/8/11 JotaComm jota.c...@gmail.com

 Olá, Miguel

 Já comentei no email anterior e fiz uma pequena descrição de como isso
 funciona. Você deu uma olhada no exemplo que mandei?

 O PostgreSQL não bloqueia a leitura (SELECT), apenas operações de
 escrita (UPDATE e DELETE).


  2009/8/11 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br

 Oi Mário, Este é o problema a leitura nunca é bloqueada.
  Fiz os testes pedidos, mas para mim não mudou nada!
 Veja:
 - Na sessão 1:
   db_teste=# BEGIN WORK;
  BEGIN
  db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT;
  LOCK TABLE
   db_teste=# UPDATE tab_material SET desc_serma = 'LAPIS Y' where
 codg_serma='10';
  UPDATE 1
  db_teste=#   *** aguardando novo comando ***
  - Na sessão 2:
db_teste=# BEGIN WORK;
   BEGIN
db_teste=# SELECT * FROM tab_material where codg_serma='10';
   codg_empr | codg_serma |  id_serma  | desc_serma

Re: [pgbr-geral] BLOQUEIO DE REGISTRO

[MIGUEL JOSE DE LIMA]

Realmente Leandro, trabalhei muito com CLIPPER e desde 1984, até hoje,
trabalho com NATURAL/ADABAS.
Vou ter que me reciclar, e aprender muita coisa nova sobre SQL e Bancos
Relacionais. Mas o que é vida, se não, um eterno aprendizado.
Mas foi muito importante esta minha primeira participação ativa no grupo.

Valeu, Muito Obrigado.

2009/8/12 Leandro Henrique Pereira Neto 
leandro-henrique.pere...@serpro.gov.br

  Miguel,

 Talvez eu seja tão velho como você já que também programei em clipper e
 num banco de mainframe (DMSII - UNISYS) que é da mesma época de tecnologia
 do ADABAS, apesar do ADABAS se considerar um banco de lista invertidas e
 hoje em dia relacional.

 Se usar o SELECT FOR UPDATE  e os comandos de DML (insert, update e delete)
 vai funcionar.
 A questão é quando você vai precisar prender o registro para atualizar o
 saldo.

 Imagine um site de vendas como o submarino. Eu usuário estou olhando um
 produto naquele momento o registro precisa está liberado para consulta, já
 que eu estou somente consultando. Aí eu resolvo fazer a compra, no momento
 que eu confirmo que quero comprar é que o sistema faz lock por alguns
 milisegundos do registro para atualizar o saldo.
 Lógico que isto pode causa uns comportamentos estranhos, tipo quando
 consultei tinha saldo mas na hora de confirmar a comprar não tinha mais e a
 compra não é confirmada (isto já ocorreu comigo na vida real num sistema
 destes de compras online).
 Mas isto é necessário quando estamos trabalho com milhares de acessos
 simultâneos de sistemas OLTP.

 Seria assim

 sessão 1 - consulta sem for update
 sessão 2 - consulta sem for update

 sessão 1 - faz o select for update e começa a transação para alterar o
 saldo

 sessão 2, sessão 3 e sessão 4 - consultam sem for update e conseguem
 consultar o saldo antigo

 sessão 2 - faz o select for update para tentar alterar o saldo também
 recebe um lock. (Aí o programa precisa definir o que fazer esperar ou
 cancelar logo tudo).

 sessão 1 - termina de altera o saldo (COMMIT na trasnsação)

 sessão 2 - consegue fazer o select já em cima do valor novo alterado pela
 sessão 1.

 A questão é que em bancos SQL não precisamos no preocupar tanto com o
 controle de lock e de transação, normalmente o funcionamento padrão do banco
 resolve, pelo menos para sistemas mais simples.

 Leandro Henrique Pereira Neto
 Administração de bancos de dados

 MIGUEL JOSE DE LIMA escreveu:

 Bom dia,
 Leandro, eu concordo com vc, talvez tenho que aprender a conviver com os
 conceitos
 de Banco de Dados Relacional e SQL..., mas confesso a vc que para mim é
 meio
 decepicionante, não conseguir LOCAR um registro para leitura e poder tratar
 isso.
 Até velho bom antigo CLIPPER fazia isso, vc imagina eu acostumado a fazer
 isso
 por logos anos, também com ADABAS.
 Mas eu gostaria, se possível, de lhe perguntar: COMO É POSSÍVEL ATUALIZAR
 UM SALDO DE QUALQUER COISA (estoque/contacorrente), SEM PRENDER O
 REGISTRO PARA LEITURA? COMO POSSO SIMULAR ISSO?
 Obs.: Como algumas pessoas já tentaram me ajudar..., informa mais uma vez
 que
  o SELECT ... FOR UPDATE não bloquei leitura!

 Obrigado!

 2009/8/11 Leandro Henrique Pereira Neto 
 leandro-henrique.pere...@serpro.gov.br

 Pelo que conheço não é uma questão do PostgreSQL e sim de bancos padrão
 SQL, pelo menos nos mais populares (SqlServer, Oracle, MySQL, PostgreSQL e
 DB2).

 O SELECT simples nunca é bloqueado (somente se usar for update).
 Porém usar todos os SQL com FOR UPDATE pode travar todo o seu sistema
 rapidinho já que somente uma transação poderá ler os dados de cada vez, como
 em sistema OLTP temos normalmente mais leitura do que alteração a coisa
 acaba ficando complicada.

 O que tem são os conceitos de transação e de consistência de leitura.

 Talvez seja o caso de você pensar o sistema em temos de bancos SQL e não
 tentar fazer no PostgreSQL o que um banco como o Adabas faz pois estruturas
 de funcionamento e implementação totalmente diferentes.

 Leandro Henrique Pereira Neto
 Administração de bancos de dados





 Charly Frankl escreveu:

  Miguel, boa noite...

 Para você bloquear os selects, faça todos com FOR UPDATE ... Ai você tem
 opções, onde para retornar logo que está ocupado utilize NOWAIT.

 Att,


 2009/8/11 JotaComm jota.c...@gmail.com

 Olá, Miguel

 Já comentei no email anterior e fiz uma pequena descrição de como isso
 funciona. Você deu uma olhada no exemplo que mandei?

 O PostgreSQL não bloqueia a leitura (SELECT), apenas operações de escrita
 (UPDATE e DELETE).


  2009/8/11 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br

 Oi Mário, Este é o problema a leitura nunca é bloqueada.
  Fiz os testes pedidos, mas para mim não mudou nada!
 Veja:
 - Na sessão 1:
   db_teste=# BEGIN WORK;
  BEGIN
  db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT;
  LOCK TABLE
   db_teste=# UPDATE tab_material SET desc_serma = 'LAPIS Y' where
 codg_serma='10';
  UPDATE 1
  db_teste=#   *** aguardando novo comando ***
  - Na sessão 2

Re: [pgbr-geral] BLOQUEIO DE REGISTRO

[MIGUEL JOSE DE LIMA]

Concordo com você. Temos que tomar muito cuidado...!
ATé +

2009/8/12 Charly Frankl carl...@gmail.com

 É uma alternativa, apesar de eu não gostar muito dela, pois sou a favor da
 delegação de responsabilidades. Neste caso, transação de banco ser de
 responsabilidade do banco... Delegando controle transacional para a
 aplicação podemos incorrer em falhas já corrigidas no banco, além de outros
 transtornos, como tornar muito complexa a implementação de código, muitas
 vezes desnecessariamente (e antes que me leve a mal, não estou falando no
 teu caso, pois nem conheço o problema).


 Mas como dito anteriormente, e uma das coisas que acho mais bacana na área
 de TI é que pra cada caso uma solução.


 Att,


 --
 Charly Frankl
 http://javadevilopers.blogspot.com/
 charlyfra...@gmail.com
 Linux user #391083




 2009/8/12 mateusgra mateus...@bol.com.br


 Resolvi esse problema na aplicação. Em Java por exemplo vc pode fazer um
 filter onde so vai dar o commit qdo toda a transação for terminada.
 E se vc for mais alem pode até esperar o subimit do cliente.

 Seguindo o exemplo da compra online ele so atualizaria o saldo e o estoque
 se o cliente confirmasse toda a compra.


 MIGUEL JOSE DE LIMA wrote:
 
  Caros, participantes...
  Sou iniciante neste mundo do PostgreSQL.
  Trabalho com outro Banco de Dados - ADABAS (UNIX SOLARIS/MAINFRAME),
  mas me incubiram de fazer testes no PostgreSQL para bloquer registros.
  Então...
 
  Estou precisando de ajuda para bloquear a leitura de um registro, ou
 seja,
  em um cenário como:
   Atualização de Estoque de um Material :
  Antes de atualizar o estoque do material selecionado eu preciso bloquear
 o
  registro para que
  nenhuma outra sessão possa obter o dado do registro.
  PRECISO DE UMA LEITURA EXCLUSIVA - TOTALMENTE RESTRITIVA.
  Estou usando o PostgreSQL 8.3.7 para os testes - em linux
  Já li e reli sobre o Isolamento de Transação, mas pode ser que eu não
  esteja
  entendendo...???
  Fiz o seguinte teste via psql:
  - Na Sessão A
db_teste=# BEGIN WORK;
BEGIN
db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT;
LOCK TABLE
db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR
 UPDATE;
resultado obtido ok!
*** aqui eu preciso bloquear todos os materiais/itens (de um pedido) -
  como ex. fiz de apenas 1 (um).
 
  - Na Sessão B:
  ** Fiz o mesmo SELECT sem a clausula FOR UPDATE:
SELECT * FROM tab_material where codg_serma='10'
 
** aqui eu obtive o resultado ok da leitura.
   Portanto, é aqui, neste ponto que não deveria permitir nenhuma
  leitura,
  já que sessão A ainda não terminou!
   E AI ALGUÉM PODE ME AJUDAR!?
 
  Obrigado!
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 

 --
 View this message in context:
 http://www.nabble.com/BLOQUEIO-DE-REGISTRO-tp24923152p24937028.html
 Sent from the PostgreSQL - Brasil mailing list archive at Nabble.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


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] BLOQUEIO DE REGISTRO

[MIGUEL JOSE DE LIMA]

Caros, participantes...
Sou iniciante neste mundo do PostgreSQL.
Trabalho com outro Banco de Dados - ADABAS (UNIX SOLARIS/MAINFRAME),
mas me incubiram de fazer testes no PostgreSQL para bloquer registros.
Então...

Estou precisando de ajuda para bloquear a leitura de um registro, ou seja,
em um cenário como:
 Atualização de Estoque de um Material :
Antes de atualizar o estoque do material selecionado eu preciso bloquear o
registro para que
nenhuma outra sessão possa obter o dado do registro.
PRECISO DE UMA LEITURA EXCLUSIVA - TOTALMENTE RESTRITIVA.
Estou usando o PostgreSQL 8.3.7 para os testes - em linux
Já li e reli sobre o Isolamento de Transação, mas pode ser que eu não esteja
entendendo...???
Fiz o seguinte teste via psql:
- Na Sessão A
  db_teste=# BEGIN WORK;
  BEGIN
  db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT;
  LOCK TABLE
  db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR UPDATE;
  resultado obtido ok!
  *** aqui eu preciso bloquear todos os materiais/itens (de um pedido) -
como ex. fiz de apenas 1 (um).

- Na Sessão B:
** Fiz o mesmo SELECT sem a clausula FOR UPDATE:
  SELECT * FROM tab_material where codg_serma='10'

  ** aqui eu obtive o resultado ok da leitura.
 Portanto, é aqui, neste ponto que não deveria permitir nenhuma leitura,
já que sessão A ainda não terminou!
 E AI ALGUÉM PODE ME AJUDAR!?

Obrigado!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] BLOQUEIO DE REGISTRO

[MIGUEL JOSE DE LIMA]

Oi Mário, Este é o problema a leitura nunca é bloqueada.
Fiz os testes pedidos, mas para mim não mudou nada!
Veja:
- Na sessão 1:
 db_teste=# BEGIN WORK;
 BEGIN
 db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT;
 LOCK TABLE
 db_teste=# UPDATE tab_material SET desc_serma = 'LAPIS Y' where
codg_serma='10';
 UPDATE 1
 db_teste=#   *** aguardando novo comando ***
- Na sessão 2:
  db_teste=# BEGIN WORK;
  BEGIN
  db_teste=# SELECT * FROM tab_material where codg_serma='10';
  codg_empr | codg_serma |  id_serma  | desc_serma
   ---++++--+--
   202   | 10 | 202010 | LAPIS Y|

É isso ai!!!??
Obrigado.

2009/8/11 Mário Oshiro mario.osh...@gmail.com

 Em SQLServer, fiz um teste parecido com o seu.

 Qdo vc faz um lock de registro ou trabela,  ele nao bloqueia a leitura
 de outras sessoes, ate' que a
 sessao de posse do lock, faça um update de algum dado do registro.

 Para bloquear o select que vc fez, faca em seguida um update com a mesmo
 where assim :

  db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR UPDATE;
  update tab_material set codg_serma='10' where codg_serma='10' ;

 teste la e depois envie o resultado.

 até mais.



 MIGUEL JOSE DE LIMA wrote:
  Caros, participantes...
  Sou iniciante neste mundo do PostgreSQL.
  Trabalho com outro Banco de Dados - ADABAS (UNIX SOLARIS/MAINFRAME),
  mas me incubiram de fazer testes no PostgreSQL para bloquer registros.
  Então...
 
  Estou precisando de ajuda para bloquear a leitura de um registro, ou
  seja,
  em um cenário como:
   Atualização de Estoque de um Material :
  Antes de atualizar o estoque do material selecionado eu preciso
  bloquear o registro para que
  nenhuma outra sessão possa obter o dado do registro.
  PRECISO DE UMA LEITURA EXCLUSIVA - TOTALMENTE RESTRITIVA.
  Estou usando o PostgreSQL 8.3.7 para os testes - em linux
  Já li e reli sobre o Isolamento de Transação, mas pode ser que eu não
  esteja entendendo...???
  Fiz o seguinte teste via psql:
  - Na Sessão A
db_teste=# BEGIN WORK;
BEGIN
db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT;
LOCK TABLE
db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR UPDATE;
resultado obtido ok!
*** aqui eu preciso bloquear todos os materiais/itens (de um pedido)
  - como ex. fiz de apenas 1 (um).
 
  - Na Sessão B:
  ** Fiz o mesmo SELECT sem a clausula FOR UPDATE:
SELECT * FROM tab_material where codg_serma='10'
 
** aqui eu obtive o resultado ok da leitura.
   Portanto, é aqui, neste ponto que não deveria permitir nenhuma
  leitura, já que sessão A ainda não terminou!
   E AI ALGUÉM PODE ME AJUDAR!?
 
  Obrigado!
 
 
 
 
  
 
  ___
  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 mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] script reload

[MIGUEL JOSE DE LIMA]

De forma geral em scripts vc deve carregar a profile da conta que vc esta
usando para executar um utilitário - conportamento do crontab.
ex.: #!/bin/bash
   .  /home/pasta/.profile   -- isto garante suas variaveis de ambiente
  e consegue executar o
utilitário!
ex.2 No caso do crontab for a conta root vc pode usar:
   su - user -c comando
Até +


2009/8/10 paulo matadr saddon...@yahoo.com.br

 Boa tarde a todos,
 tava precisando de uma maozinha nesse script,altera linha referente ao
 parametro  maintenance_work_mem dentro do  conf ,comentando a linha antiga
 que tem valor menor,
 a ideia e altera o maintenance_work_mem a noite pra facilitar meu vaccum..e
 depois rodar outro antes do espediente comercial voltando o valor antigo.
 # /bin/sh
 diretorio_conf=/usr/local/pgsql/data
 sed -i s/maintenance_work_mem/#maintenance_work_mem/g
 $diretorio_conf/postgresql.conf
 sed -i s/##maintenance_work_mem/maintenance_work_mem/g
 $diretorio_conf/postgresql.conf
 /usr/local/pgsql/bin/pg_ctl reload
 Rodando na mão ele roda beleza, quando ponho na cron so funciona o sed e
 nada de reload.
 Alguem ja viu ou  passo por isso?
 Agradeço.


 --
 Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 
 10http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/-
 Celebridadeshttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/celebridades/-
 Músicahttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/m%C3%BAsica/-
 Esporteshttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/esportes/

 ___
 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