Re: [pgbr-geral] RESTAURAR BACKUP
Em 24 de janeiro de 2017 14:10, José Mello Júnior < jose.mello.jun...@gmail.com> escreveu: > No evento do Windows encontrei a seguinte mensagem: > > pg_ctl: este diretório de dados parece já estar executando um postmaster > > o que posso fazer? > > > > Em 24 de janeiro de 2017 14:01, José Mello Júnior < > jose.mello.jun...@gmail.com> escreveu: > >> Quando retorno para a pasta data original, tudo se normaliza, o problema >> é que as informações das quais necessito estão na pasta em que o banco não >> consegue iniciar o serviço. >> >> Att >> >> >> Em 24 de janeiro de 2017 10:32, POWER Informática < >> power.informatica@gmail.com> escreveu: >> >>> Só um teste, que alias já deves ter feito... >>> Volta a pasta original e tenta iniciar o PostgreSql. >>> >>> >>> Carlos Susviela >>> >>> >>> >>> Em 23/01/2017 19:39, José Mello Júnior escreveu: >>> >>> Elaborei um programa para Windows, onde faço cópia da pasta "data" >>> inteira. Tomei o cuidado de parar o serviço antes de realizar a copia e >>> essa cópia joguei dentro de um arquivo compactado. Após isso feito, apenas >>> renomeei a pasta data para data_ori e coloquei novamente a pasta data >>> recuperada em seu lugar. O serviço simplesmente não sobe, já revisei as >>> permissões de acesso. O que faltou? >>> >>> Em tempo: Mesma máquina. >>> >>> -- >>> Mello Júnior >>> 41.3252-3555 >>> >>> >>> ___ >>> pgbr-geral mailing >>> listpgbr-ge...@listas.postgresql.org.brhttps://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> >>> >>> -- >>> - >>> Carlos Alberto N. Susviela >>> >>> (48) 984 466 384 - OI >>> (55) 9994-8782 - Vivo >>> (55) 8446-6762 - OI >>> (55) 3242-5427 - Comercial >>> >>> Rua João Manoel, 912 - CEP: 97573-684 >>> Centro - Santana do Livramento / RS >>> -- >>> Site.: http://www.powerinformatica.com.br >>> Facebook.: https://www.facebook.com/powerinformaticaliv >>> Pinterest: https://www.pinterest.com/powerinformatic/ >>> Twitter..: https://twitter.com/susviela >>> Blog.: https://susviela.wordpress.com/ >>> Plus.: https://plus.google.com/111258731965583811107/ >>> Linkedin.: >>> http://br.linkedin.com/pub/carlos-alberto-nunes-susviela/91/942/4ba >>> -- >>> >>> >>> ___ >>> pgbr-geral mailing list >>> pgbr-geral@listas.postgresql.org.br >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> >> >> >> >> -- >> Mello Júnior >> 41.3252-3555 >> > > > > -- > Mello Júnior > 41.3252-3555 > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > pg_ctl: este diretório de dados parece já estar executando um postmaster Se fosse linux, eu teria que deletar o file do processo postmaster.pid da pasta que está sendo restaurada. -- 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] MIGRAÇÃO POSTGRESQL - LINUX (CISC) para o Solaris (RISC) - DESEMPENHO RUIM NO SOLARIS
Boa tarde a todos. Trabalhamos com o PostgreSQL em nossa empresa. Precisamos migrá-lo da plataforma Linux (arquitetura CISC) para a plataforma Unix (arquitetura RISC). Após vários testes, estamos em dúvida quanto à performance da arquitetura RISC. Fizemos vários testes de pg_dump e de desempenho de queries. Em todos os testes, a plataforma Unix foi mais lenta do que a plataforma Linux. - Tempo pg_dump do Linux: 5 horas - Tempo pg_dump do Unix: 7 horas, 6 horas - Queries no Unix - mais lentas Exemplo: Linux - query x = 1.8 segundos UNIX - query x = 2,8 segundos Fizemos também algumas modificações no ambiente UNIX - RISC (T5) - como sistema de arquivos do armazenamento para ZFS e UFS, mas surtiram poucas melhoras na performance. Sendo assim, pedimos ajuda aos mestres... - Onde está o problema? - Existe um problema com a combinação "PostgreSQL e RISC"? - O problema de performance no RISC advém da arquitetura RISC, do UNIX ou do SGBD? Desde já, agradeço. Abaixo estão descritos os dois ambientes: ambiente LINUX (CISC) : - CentOS Linux * Ambiente de produção com aplicações DIVERSAS QUE FUNCIONA CUNCURRENTLY - 3.10.0-229.7.2.el7.x86_64 GNU / Linux - 16 GB de Memória - SHMMAX = 12884901888 (12GB) - PostgreSQL 9.4.4 - Cluster 64 bits. * Shared_buffers = 4GB * Work_mem = 32MB * Autovacuum_work_mem = 256 * Max_stack_depth = 4MB * Wal_level = arquivo * Outros parâmetros = default ambiente UNIX (CISC - SUN SOLARIS SPARK T5 ) * ambiente de teste - SEM aplicativos em execução de qualquer aplicação. - Uname -a -> SunOS 5.10 Generic_147147-26 sun4v sun4v SPARC - Liberação -> Oracle Solaris 10 SPARC 1/13 s10s_u11wos_24a Copyright (c) 1983, 2013, Oracle e / ou suas afiliadas. Todos os direitos reservados. Montados 17 de janeiro de 2013 - GLOBAL Solaris = 128 GB (Memória RAM) - A instalação POSTGRESQL foi realizada na a "zona" solaris - Projeto Para o usuário: postgres user.postgres projid: 100 comentar: "Postgres" usuários: (nenhum) grupos: (nenhum) attribs: process.max-msg-messages = (priv, 42, negar) process.max-sem-ops = (priv, 2048, negar) process.max-msg-qbytes = (priv, 42, negar) process.max-sem-nsems = (priv, 14000, negar) project.max-msg-ids = (priv, 22000, negar) project.max-sem-ids = (priv, 14000, negar) project.max-SHM-ids = (priv, 4096, negar) project.max-shm-memory = (priv, 6442450944, negar) - PostgreSQL 9.5.4 - Cluster 64 bits. * Shared_buffers = 6GB * Work_mem = 32MB * Autovacuum_work_mem = 256 * Max_stack_depth = 4MB * Wal_level = mínimo * Outros parâmetros = default -- 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] Como acompanhar execução de tarefas longas
> > Gostaria de saber se existe alguma consulta que estime o tempo restante do >> processo do dump, bem como outras estatísticas, tal como existe no Oracle >> (v$session_longops). >> -- >> Rosana de Oliveira Santos >> >> > Olá Rosana, > > Não há como saber o tempo restante não... Você consegue acompanhar o que > está "acontecendo" no banco através da tabela pg_stat_activity: > > SELECT * FROM pg_stat_activity > > > Lucas > Humm... Conheço esta view Lucas. Mas a pg_stat_activity não contém as informações que quero. Pesquisei um pouco mais e vi que haverá facilidades deste gênero no release 9.6 do Postgresql. https://wiki.postgresql.org/wiki/Query_progress_indication -- 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] Como acompanhar execução de tarefas longas
Prezados, Boa noite. Utilizo Postgresql v 9.5.4 Agendei um dump na minha crontab. O mesmo já se encontra em execução. Gostaria de saber se existe alguma consulta que estime o tempo restante do processo do dump, bem como outras estatísticas, tal como existe no Oracle (v$session_longops). Agradeço desde já. -- 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] Instação Postgresql v. 9.5.* ( 64 bits) no Solaris 10
Estamos com problemas na instalação do Postgresql - 64 bits on sparc-sun-solaris10. Fizemos várias tentativas. O fato é que as versões mais recentes (9.5.3, 9.5.4), estão gerando erro. Não obtivemos sucesso nas instalações (nem via pacote, nem via compilação). Na compilação, ocorre erro ao final, devido à lib ibreadline.so.6 Apesar de atualizarmos esta biblioteca, o erro persiste. Via pacote, a instalação quase procede, porém o psql não funciona e dá o seguinte erro ao chamar o psql: ld.so.1: psql: fatal: relocation error: file /opt/readline2/lib/libreadline.so.6: symbol tgetent: referenced symbol not found Neste caso, mesmo sem psql, pelo pgadmin funciona. Após várias outras tentativas com versões distintas, li em https://www.postgresql.org/message-id/8048.1442866...@sss.pgh.pa.us onde alguém passou pelo mesmo problema na versão 9.4.2 e posteriores. A partir de então, instalei a versão 9.4 (pacote) e funcionou. Após todos os testes, pergunto: - Alguém já passou por este problema? - Será que as versões 9.5.* estão realmente com problemas ou tenho que rever a configuração da lib readline do Solaris? Se puderem ajudar, agradeço fortemente. 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
Re: [pgbr-geral] SPARC SOLARIS - Postgresql 32bits ou 64bits
2016-08-18 12:23 GMT-03:00 Leandro Guimarães Faria Corcete DUTRA < l...@dutras.org>: > Le 18 août 2016 09:57:09 GMT-03:00, MIGUEL JOSE DE LIMA < > mig...@inlocsistemas.com.br> a écrit : > >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? > > Depende. > > > >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 você for usar mais do que a memória endereçável em 32 bits, use 64. Se > não, vide o texto que citaste? > > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org > +55 (61) 9302 2691 (Vivo) ICQ/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 Miguel, No site do Postgresql, há uma explicação razoável sobre isto: "shared_buffer acima de 2GB são suportados apenas por sistema de 64-bits. " (FONTE: https://www.postgresql.org/message-id/attachment/23634/postgresql.conf.simple ) Matematicamente, em uma compilação de 32 bits, cada processo está limitado a 4 GB de espaço de endereço, de que (pelo menos no Linux) 1 GB é reservado para o kernel. Então, se você está executando um um Postgresql de 32 bits (UNIX-like operating system) você está limitado a usar no máximo 2GB or 2.5GB (shared_buffer). Precisa de mais do que 4 GB para shared_buffer? Então, considere fortemente a fazer um upgrade para o PostgreSQL 64-bit. (FONTE2: http://rhaas.blogspot.com.br/2011/05/sharedbuffers-on-32-bit-systems.html) É o que a literatura diz. 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
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
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
[pgbr-geral] Timeout para consultas idle
Prezados, boa tarde! Temos uma aplicação com o banco de dados rodando no Postgresql 9.2.9 que gera constantemente várias consultas com state = 'idle' na view pg_stat_activity. Estou matando os processos inúteis explicitamente com o comando pg_terminate_backend(pid). Posso também configurar na crontab um script para isto. Todavia, meus colegas de S.O. estão me indagando porque o Postgresql não controla isto no banco? Gostaria de saber se há como controlar estas consultas utilizando um timeout -- existe um parâmetro no postgresql.conf para isto? ;-) procurei e não encontrei... 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
Re: [pgbr-geral] Timeout para consultas idle
Obrigada! Em 20 de novembro de 2014 14:06, Douglas Fabiano Specht douglasfabi...@gmail.com escreveu: Em 20 de novembro de 2014 13:58, Rosana de Oliveira rosana.pi...@gmail.com escreveu: Prezados, boa tarde! Temos uma aplicação com o banco de dados rodando no Postgresql 9.2.9 que gera constantemente várias consultas com state = 'idle' na view pg_stat_activity. Estou matando os processos inúteis explicitamente com o comando pg_terminate_backend(pid). Posso também configurar na crontab um script para isto. Todavia, meus colegas de S.O. estão me indagando porque o Postgresql não controla isto no banco? Gostaria de saber se há como controlar estas consultas utilizando um timeout -- existe um parâmetro no postgresql.conf para isto? ;-) procurei e não encontrei... 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 boa tarde, o postgres tem sim controle de conexão nao finalizadas pela aplicação, veja as opções: #tcp_keepalives_idle = 0 #tcp_keepalives_interval = 0 #tcp_keepalives_count = 0 costumo utilizar 180, 60, 3 respectivamente, mas faça os testes e veja se serva para vc. -- Douglas Fabiano Specht ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- 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] effective_cache_size
Caríssimos, Estou com dúvida quanto ao uso do parâmetro effective_cache_size utilizado pelo PostgreSQL. A máquina em que roda o PostgreSQL (versão 9.2.3) tem Red Hat 6.3 com 12GB de RAM. O effective_cache_size está com o valor padrão: 128 MB O Pgtune sugeriu aumentar para 7680 MB (vide abaixo na figura 1). VALOR REALSUGESTÃO DO PGTUNEParâmetropostgresql.confpsqlotimizado.conf default_statistics_target 10050maintenance_work_mem 256MB640MB constraint_exclusion partitiononcheckpoint_completion_target0.5 0.9 effective_cache_size128MB 7680MBwork_mem 32 MB64MBwal_buffers-1 8MB checkpoint_segments 316shared_buffers3200 MB 2560MBmax_connections10080 Figura 1 - Correlação dos parâmetros do postgresql.conf Pergunta-se: - Onde a área do effective_cache_size é alocada? - Segundo o help do próprio Postgresql... é utilizado para fins estimativos... como assim? - Esta alocação é interna, ou é somente um valor constante para fins de cálculos do plano de execução? Desde já agradeco. -- 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] effective_cache_size
Em 27 de junho de 2014 13:00, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: - Onde a área do effective_cache_size é alocada? Não é alocada. Vide abaixo. - Segundo o help do próprio Postgresql... é utilizado para fins estimativos... como assim? É o valor que o planejador de consultas usa como probabilidade de encontrar uma página de dados em cache. - Esta alocação é interna, ou é somente um valor constante para fins de cálculos do plano de execução? É somente um valor para cálculo de planos de execução. Ele inclusive pode ser alterado para uma sessão como: SET effective_cache_size = X; Você pode alterar esse parâmetro sem medo algum de ter falta de memória, todavia, seus planos de execução serão mais ou menos eficientes dependendo de como você o ajusta. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Obrigada. Valeu demais! Foi show de bola! -- 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] Recomendação de cursos
Em 3 de junho de 2014 23:01, Vinícius Aquino do Vale aquino.v...@gmail.com escreveu: O Curso de Postgresql da 4Linux é um dos melhores. http://www.4linux.com.br/cursos/postgreSQL-alta-performance 2014-06-03 13:39 GMT-03:00 JotaComm jota.c...@gmail.com: +1 2014-06-03 12:43 GMT-03:00 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: 2014-06-03 11:55 GMT-03:00 Alessandro Lima grandegoia...@gmail.com: Recomendam os cursos da timbira.com.br: Recomendo tudo da Timbira. -- 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 -- JotaComm http://jotacomm.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 Fiz o curso na 4Linux e na Dextra Gostei muito da 4 Linux e a recomendo!!! -- 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] SQL Art
2014-04-02 17:11 GMT-03:00 Fabrízio de Royes Mello fabri...@timbira.com.br : On 02-04-2014 17:06, Fabrízio de Royes Mello wrote: On 02-04-2014 13:30, Fábio Telles Rodriguez wrote: Roda aí select * from (select array_to_string(array_agg(CASE WHEN (power((xx.x-25),2)/130+power((yy.y-25),2)/130)=1 THEN '$' WHEN (sqrt(power(xx.x-20,2)+power(yy.y-20,2)))2 THEN '#' WHEN (sqrt(power(xx.x-20,2)+power(yy.y-30,2)))2 THEN '#' WHEN (sqrt(power(xx.x-29,2)+power(yy.y-25,2)))4 THEN '#' WHEN (power((xx.x-10),2)/40+power((yy.y-10),2)/40)=1 THEN '$' WHEN (power((xx.x-10),2)/40+power((yy.y-40),2)/40=1) THEN '$' ELSE ' ' END),' ') as cartoon from (select generate_series(1,40) as x) as xx,(select generate_series(1,50) as y) as yy group by xx.x order by xx.x) as co_ord; Tem a manha de fazer um melhor? http://feedproxy.google.com/~r/blogspot/rFRqt/~3/ oTGb8aK0Qt4/cartoon-in-pg.html Legal. Já viu esse? https://wiki.postgresql.org/wiki/Mandelbrot_set Na verdade no wiki tem vários exemplos legais: https://wiki.postgresql.org/wiki/Category:Fun_Snippets Vou adicionar lá esse que o Telles contribuiu tb... :-) Att, -- Fabrízio de Royes Mello 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 * Que gracinha!!!* * Os DBAS também amam...* * rsss.* *-- 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] PgFouine funciona no PostgreSQL 9.3?
Em 11 de março de 2014 09:51, Matheus de Oliveira matioli.math...@gmail.com escreveu: 2014-03-10 17:14 GMT-03:00 Rosana de Oliveira rosana.pi...@gmail.com: Boa tarde, Boa tarde. Agora a mensagem veio corretamente... :) Estou aprendiz de DBA Opa. A lista vai ser de grande ajuda na sua empreitada. Também recomendo que tente alguns cursos, se possível. e atualmente estou tentando utilizar o Pgfouine para visualizar o relatório do log em html. ... *A configuração do postgresql.conf atual (após inúmeros outros testes) é:* *log_destination = 'syslog'* *logging_collector=on* *log_directory = '/var/log/postgresql/'* *log_min_messages= info* *log_min_duration_statetement = 0* *log_line_prefix = 'user=%u, db=%d'* *log_statement= 'none'* *lc_messages='C'* O conteúdo do pg_log é: user=, db=LOG: sistema de banco de dados foi desligado em 2014-03-06 11:11:14 BRT ... *Pergunta-se:* *- o PgFouine funciona no PostgreSQL 9.3? * Sim. Sem problemas. *- o arquivo log que devo gerar é este mesmo? Estou usando syslog.* Não, você tem que configurar as mensagens de log para locale em inglês, veja que as suas estão aparecendo em português. O estranho é que seu lc_messages está como C, que deveria produzi-las em inglês. Tente colocar explícito: lc_messages = 'en_US.UTF8' Conecte-se no PostgreSQL e veja o valor real e como ele foi alterado (pode ter sido alterado em outro lugar, como na chamada do postmaster): SELECT name, setting, context, source, sourcefile, sourceline FROM pg_settings WHERE name = 'lc_messages'; *- como vocês indicam ser a melhor configuração de log para o postgresql.conf?* O primeiro passo é usar as mensagens em inglês. Depois também recomendo outros logs, como: log_checkpoints = on log_connections = on log_disconnections = on log_lock_waits = on log_temp_files = 0 *- como não consegui, agora estou tentando usar o PgBadger para relatórios de log, mas parece que o PgFouine é melhor.* *O que vocês acham?* É exatamente o contrário. O pgBadger é o sucessor do PgFouine, e na minha experiência é infinitamente melhor em vários sentidos, o relatório é mais completo, a performance e estabilidade do sistema é bem maior. Creio eu que o surgimento do pgBadger simplesmente fez com que o projeto do PgFouine acabasse e ficasse em desuso. Hoje não vejo mais ninguém usado o PgFouine, e não recomendo que siga esse caminha, vá direto para o pgBadger. 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 *Valeu gente, obrigada!* *Vou usar o PgBadger...* *Quanto ao aprendizado de DBA... Já estou inscrita em 02 cursos de DBA: um na 4Linux e outro na Dextraining... só estou aguardando o curso iniciar... enquanto isso estou estudando por conta própria...para aproveitar mais o curso...* -- 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] problema de conexao unrecognized winsock error 10061
___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- 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] problema de conexao unrecognized winsock error 10061
desculpem-me!!! mil perdões Em 10 de março de 2014 17:08, Matheus de Oliveira matioli.math...@gmail.com escreveu: 2014-03-10 17:06 GMT-03:00 Rosana de Oliveira rosana.pi...@gmail.com: Boa tarde, Olá Rosana, boa tarde. Por favor, não sequestre o assunto de outra thread, envie um novo e-mail para lista com o novo assunto e ficaremos felizes em ajudar. Obrigado, -- 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 -- 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
