Re: [pgbr-geral] Acúmulo de Wal no servidor Master
Em 4 de abril de 2018 09:37, Cleiton Luiz Domazak <cleitondoma...@gmail.com> escreveu: > > > 2018-04-04 9:14 GMT-03:00 Felippi Cunegundes Laender < felippilaen...@gmail.com>: >> >> Olá a todos. >> >> O Assunto wal me deixa um pouco confuso as vezes. Quando acho que estou entendendo alguma coisa, vem os problemas e pronto, não entendi nada do que estudei. >> >> Meu cenário é o seguinte: Fiz uma replicação com repmgr para testar e funcionou beleza. Após meus testes de tornar master em standby, standby em master, etc excluí o servidor de standby mantendo as configurações de replicação no master. >> >> Sobre o postgresql.conf no período de replicação o archive_mode = on e o archive_command = '/bin/true'. wal_keep_segments = 100. Após ver que meu /var estava próximo ao estouro, diminuí meu wal_keep_segments = 10, nada alterou. >> >> Gostaria de saber se tem algum modo efetivo, mais elegante de excluir esses arquivos wal. A única opção na minha mente é um rm -r nos arquivos mantendo apenas dois últimos dias. > > > Siga esse procedimento, só tome cuidado para não inverter os valores :) > > https://erpnani.blogspot.com.br/2016/01/postgresql-how-to-clean-pgxlog.html Muito cuidado com a recomendação desse post, pois o pg_resetxlog deve ser utilizado em último caso, inclusive a documentação oficial cita o que segue no primeiro parágrafo: "pg_resetxlog clears the write-ahead log (WAL) and optionally resets some other control information stored in the pg_control file. This function is sometimes needed if these files have become corrupted. It should be used only as a last resort, when the server will not start due to such corruption." Vide: https://www.postgresql.org/docs/9.4/static/app-pgresetxlog.html 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
[pgbr-geral] Normalização e Chaves Primárias
Boa tarde, Interessante artigo do Dimitri sobre $SUBJECT [1]. Att, [1] https://tapoueh.org/blog/2018/03/database-normalization-and-primary-keys/ -- 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
Re: [pgbr-geral] Registrando tempo de "downtime" para efeito de SLA
Em 6 de março de 2018 09:53, Alexsander Rosa <alexsander.r...@gmail.com> escreveu: > > Em 5 de março de 2018 17:10, Fabrízio de Royes Mello < fabri...@timbira.com.br> escreveu: >> >> Nesse caso somente olhando os logs mesmo... > > > Bom, copiei manualmente dos logs e fiz o INSERT à mão, estes primeiros meses de 2018 ficaram assim: > > rednaxel-server:rnge4=> SELECT * FROM vw_webservice_level WHERE servico = 'postgresql' ORDER BY ano, mes; > servico | ano | mes | downtime | dias | segundos | svc_lvl > +--+-+--+--+--+-- > postgresql | 2018 | 1 | 22.4383 | 31 | 2678400 | 99.9992 > postgresql | 2018 | 2 | 0. | 28 | 2419200 | 100. > (2 rows) > > Em março ainda não houve downtime mas já vi que o servidor está pedindo reboot... Daí eu procuro no log, sem problemas. > Show de bola... publica a solução lá no github pra contribuir com resto da galera. 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
Re: [pgbr-geral] Registrando tempo de "downtime" para efeito de SLA
Em 5 de março de 2018 16:47, Alexsander Rosa <alexsander.r...@gmail.com> escreveu: > > Em 5 de março de 2018 15:43, Fabrízio de Royes Mello < fabri...@timbira.com.br> escreveu: >> >> >> Pensando melhor sobre o seu caso, vc consegue sim obter ambas informações: >> >> 1) Se o servidor estiver online vc executa a pg_postmaster_start_time() >> >> 2) Se o servidor estiver offline entao vc pode pegar o valor de 'pg_control last modified:' no pg_controldata, ex: >> >> $ pg_controldata -D ~/.pgvm/clusters/10.1/main | grep -E '(Database cluster state|pg_control last modified)' >> Database cluster state: shut down >> pg_control last modified: Seg 05 Mar 2018 15:40:18 -03 >> > > Estou usando o pg_postmaster_start_time(), criei um indicador "Uptime PG" no dashboard. Para uma parada controlada dá pra usar o pg_controldata pra ver o last_modified mas o caso de uso mais comum é a reinicialização do S.O. para atualizações, geralmente fora do horário comercial. > Nesse caso somente olhando os logs mesmo... -- 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
Re: [pgbr-geral] Registrando tempo de "downtime" para efeito de SLA
Em 5 de março de 2018 15:29, Fabrízio de Royes Mello < fabri...@timbira.com.br> escreveu: > > [...] > Pensando melhor sobre o seu caso, vc consegue sim obter ambas informações: 1) Se o servidor estiver online vc executa a pg_postmaster_start_time() 2) Se o servidor estiver offline entao vc pode pegar o valor de 'pg_control last modified:' no pg_controldata, ex: $ pg_controldata -D ~/.pgvm/clusters/10.1/main | grep -E '(Database cluster state|pg_control last modified)' Database cluster state: shut down pg_control last modified: Seg 05 Mar 2018 15:40:18 -03 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
Re: [pgbr-geral] Registrando tempo de "downtime" para efeito de SLA
Em 5 de março de 2018 14:36, Alexsander Rosa <alexsander.r...@gmail.com> escreveu: > > Obrigado pela resposta! Neste caso eu vou ter que fazer um polling, certo? Eu gostaria de uma precisão abaixo de 1 minuto (ou seja, não dá pra usar o CRON), porém não quero ficar toda hora chamando o pg_isready pois isso certamente vai influenciar na carga do servidor. Além disso, quando o S.O. for reiniciado meu programa em C vai cair também. > > O ideal seria uma função análoga à pg_postmaster_start_time() porém com o último shutdown. > Talvez seja possível criar uma "pg_postmaster_last_shutdown()" para obter esta informação. > > Eu sei que nosso servidor PG foi reiniciado, pela última vez, dia 30 de janeiro: > > SELECT pg_postmaster_start_time(); >pg_postmaster_start_time > --- > 2018-01-30 07:33:29.438349-02 > (1 row) > > No caso eu sei que está no ar desde Janeiro porém eu não sei que horas, no dia 30/01, o servidor foi parado. Olhando no log temos: > 2018-01-30 07:33:07.278 -02 [1212] LOG: autovacuum launcher shutting down > 2018-01-30 07:33:07.373 -02 [1209] LOG: shutting down > 2018-01-30 07:33:07.440 -02 [1195] LOG: database system is shut down > 2018-01-30 07:33:29.439 -02 [1350] LOG: database system was shut down at 2018-01-30 07:33:07 -02 > > Veja que o servidor SABE que o shutdown ocorreu às 2018-01-30 07:33:07 -02 (no caso foi uma alteração no .conf). > Resta saber se esta informação está ficando gravada em algum lugar (além do texto do log) e como recuperá-la. > > Alexsander, Atualmente o PostgreSQL só persiste essa informação de Startup e Shutdown nos logs. A função pg_postmaster_start_time() apenas retorna o valor interno de uma global chamada PgStartTime que ele seta ao iniciar o postmaster (vide src/backend/postmaster/postmaster.c), mas não persiste em nenhum lugar. Talvez até fosse uma idéia adicionar isso ao global/pg_control e obter atraves do utilitário pg_controldata e termos isso a nível SQL usando a função pg_control_init() talvez... mas teriamos que discutir isso lá na -hackers, isso se já não foi e por algum motivo não foi implementado. 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
Re: [pgbr-geral] PESQUISAR HISTÓRICO
Em 16 de janeiro de 2018 16:29, Fábio Telles Rodriguez < fabio.tel...@gmail.com> escreveu: > > Realmente, o link do histórico está quebrado. Só tem os archives em https://listas.postgresql.org.br/pipermail/pgbr-geral/ > ... por favor evite top-post... @Fábio Realmente o link não está funcionando, e muito provavelmente desde a migração da infra-estrutura e de termos aposentado o antigo drupal. @Miguel O que a página antiga fazia era nada mais do que uma chamada ao google para pesquisar nos archives da lista, algo como "site:https://listas.postgresql.org.br/pipermail/pgbr-geral; Um Pull-Request [1] pra adicionar isso de novo no site é muito bem vindo. Att, [1] https://github.com/postgresql-br/website-src -- 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
Re: [pgbr-geral] pg_class
Em 15 de janeiro de 2018 12:35, Mauricio Sysmo Sistemas < mauriciomart...@sysmo.com.br> escreveu: > > Boa tarde a todos, depois de excluído um registro da pg_class te uma tabela tem como restaurar ? > Registros na pg_class são gerados por CREATE TABLE, CREATE INDEX, etc Conte um pouco mais sobre o seu problema. 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
Re: [pgbr-geral] Definição
Em 24 de novembro de 2017 16:58, Tiago Brasil <neotbra...@gmail.com> escreveu: > > > create table t2 > ( c1t1 integer, > c2t2 integer, > c3t2 integer, > primary key (c1t1, c2t2), > foreign key (c1t1) references t1 (c1t1), > unique (c2t2)); **n necessita dessa linha visto que primary key ja sao unique e not null por padrão > > De resto está correto. > Depende, porque se a cardinalidade do modelo for 1:1 então ele precisará essa restrição, ou melhor, colocar ela como PK na t2. 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
Re: [pgbr-geral] como descobrir se uma procedure foi modificado no postgresql
Em ter, 21 de nov de 2017 às 18:57, Amir <here...@gmail.com> escreveu: > Boa noite... > > Com saber se uma procedure foi modificada, no banco > Se vc não está com log de DDL habilitado não vejo outra forma de saber. -- 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
Re: [pgbr-geral] Apostila ou Livro de PostGreSql
Em 10 de outubro de 2017 11:23, Andre Fernando Dominguez < andrefdoming...@gmail.com> escreveu: > > Bom dia Pessoal. > > Sou novo em bancos de dados e gostaria de saber se alguém poderia me > enviar material sobre PostgreSQL. > > Gostaria de materiais do Básico ao avançado, pois meu conhecimento com > esse tipo de banco de dados é praticamente nulo. > André, Comece pela documentação oficial [1], depois com google vc encontra artigos, vídeos, tutorais. Att, [1] https://www.postgresql.org/docs/current/static/index.html -- 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
Re: [pgbr-geral] Listar todos as colunas com valor default definido
Em 9 de outubro de 2017 17:18, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:
>
>
> Em 9 de outubro de 2017 17:12, André Ormenese <aormen...@gmail.com>
escreveu:
> >
> > Boa tarde
> >
> > Preciso listar todos as colunas, de todas as tabelas, que tenham o
valor default definido. Independente do valor configurado.
> > Onde acho estas informações no catalogo do PostgreSQL 9.6.5 ?
> >
>
> André,
>
> Essa informação fica armazenada na tabela pg_attrdef [1] do catálogo.
>
> Att,
>
> [1] https://www.postgresql.org/docs/current/static/catalog-pg-attrdef.html
>
Apenas para ilustrar o que comentei no email anterior:
fabrizio=# CREATE TABLE foo (f1 SERIAL PRIMARY KEY, f2 TIMESTAMP, f3 TEXT
DEFAULT 'bar', f4 INTEGER);
CREATE TABLE
fabrizio=# SELECT a.attrelid, a.attname, b.adsrc FROM pg_attribute a JOIN
pg_attrdef b ON b.adrelid = a.attrelid AND b.adnum = a.attnum where
attrelid = 'foo'::regclass;
attrelid | attname | adsrc
--+-+-
102722 | f1 | nextval('foo_f1_seq'::regclass)
102722 | f3 | 'bar'::text
(2 rows)
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
Re: [pgbr-geral] Listar todos as colunas com valor default definido
Em 9 de outubro de 2017 17:12, André Ormenese <aormen...@gmail.com> escreveu: > > Boa tarde > > Preciso listar todos as colunas, de todas as tabelas, que tenham o valor default definido. Independente do valor configurado. > Onde acho estas informações no catalogo do PostgreSQL 9.6.5 ? > André, Essa informação fica armazenada na tabela pg_attrdef [1] do catálogo. Att, [1] https://www.postgresql.org/docs/current/static/catalog-pg-attrdef.html -- 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
Re: [pgbr-geral] Tamanho das colunas de uma tabela em GB
Em 6 de outubro de 2017 13:54, Sebastian Webber <sebast...@swebber.me> escreveu: > > > > Em sex, 6 de out de 2017 às 12:05, Fábio Telles Rodriguez < fabio.tel...@gmail.com> escreveu: >> >> Em 6 de outubro de 2017 11:54, Sebastian Webber <sebast...@swebber.me> escreveu: >>> >>> >>> >>> Em sex, 6 de out de 2017 às 11:17, Franklin Anderson de Oliveira Souza < frankli...@gmail.com> escreveu: >>>> >>>> Bom dia a todos ! >>>> >>>> Eu consigo ver o tamanho de um database e de suas tabelas, mas gostaria de saber o tamanho da colunas também. Exemplo: Se tenho uma tabela de 4 colunas com 10 Gb de tamanho, quantos GB tem cada uma das 4 colunas ?! >>> >>> >>> Dá uma olhada na função pg_column_size[1]. >>> >>> [1] https://www.postgresql.org/docs/current/static/functions-admin.html#functions-admin-dbsize >>> >> >> Esta função só dá o tamanho de um único valor. > > > Nesse caso seria ainda mais fácil somar os dados de todas as linhas: > > SELECT pg_size_pretty(pg_column_size( col)) from tabela; > Não, dessa forma ele irá varrer toda tabela e calcular toda a linha, portanto bem mais custoso dependendo do tamanho da mesma. E faltou um "SUM" na sua query. A opção que o Telles comentou é a mais adequada para grande maioria dos cenários. 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
Re: [pgbr-geral] [PGBR2017] **URGENTE** Prêmio Destaques Comunidade 2016/2017
Em 30 de agosto de 2017 16:51, Fábio Telles Rodriguez < fabio.tel...@gmail.com> escreveu: > >> b) Na primeira etapa, cada membro da lista poderá indicar até três nomes para cada uma das categorias do prêmio: >> * Contribuição com código no PostgreSQL; > > Fabrízio de Royes Mello, > Matheus Oliveira Adicionaria também o Euler, pois ele sempre está envolvido com alguma revisão de código ao menos. >> >> * Contribuição com código em ferramentas livres relacionadas ao PostgreSQL: Nesta categoria sugiro adicionar: * Euler Taveira: - wal2json (https://github.com/eulerto/wal2json) - pgquarrel (https://github.com/eulerto/pgquarrel) * Dickson Guedes - telegram_fdw (https://github.com/guedes/telegram_fdw) * Willian Ivanski - OminiDB (https://omnidb.org) >> * Pessoa que melhor contribuiu na lista pgbr-geral; > > Euler Taveira > Sebastian Webber > Fabrízio de Royes Mello > Matheus Oliveira > Flávio Gurgel >> * Melhor contribuição na organização da comunidade brasileira; > > Sebastian Webber > Indiscutivel!!! >> * Melhor artigo técnico publicado nos últimos 2 anos. > > Euler Taveira > Fábio Telles Rodrigues (o savepoint nunca morre... hehehe) 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
Re: [pgbr-geral] [PGBR2017] **URGENTE** Prêmio Destaques Comunidade 2016/2017
Em 29 de agosto de 2017 13:43, Fabrízio de Royes Mello < fabri...@timbira.com.br> escreveu: > Pessoal, > > Similar ao que foi realizado em 2015 iniciaremos com *URGÊNCIA* com os > procedimentos para a premiação dos destaques da Comunidade nos anos de 2016 > e 2017 durante o PGBR2017. > > A dinâmica: > > a) Os destaques referem-se aos anos de 2016 e 2017; > > b) Na primeira etapa, cada membro da lista poderá indicar até três nomes > para cada uma das categorias do prêmio: > * Contribuição com código no PostgreSQL; > * Contribuição com código em ferramentas livres relacionadas ao > PostgreSQL: > * Pessoa que melhor contribuiu na lista pgbr-geral; > * Melhor contribuição na organização da comunidade brasileira; > * Melhor artigo técnico publicado nos últimos 2 anos. > > c) A indicação dos membros na primeira etapa deverá ser feita por esta > lista, até o dia 08/09/2016; > > d) Os cinco nomes mais indicados na lista em cada categoria (caso exista > tal quantidade), concorrerão ao prêmio na segunda etapa; > > e) Na segunda etapa, uma comissão avaliará as indicações e decidirá pelos > vencedores em cada categoria até dia 16/09/2017 onde serão divulgados > durante o encerramento do PGBR2017. > > E ai pessoal... precisamos de nomes??? Qualquer um pode ser indicado e/ou indicar alguém. 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
[pgbr-geral] [PGBR2017] **URGENTE** Prêmio Destaques Comunidade 2016/2017
Pessoal, Similar ao que foi realizado em 2015 iniciaremos com *URGÊNCIA* com os procedimentos para a premiação dos destaques da Comunidade nos anos de 2016 e 2017 durante o PGBR2017. A dinâmica: a) Os destaques referem-se aos anos de 2016 e 2017; b) Na primeira etapa, cada membro da lista poderá indicar até três nomes para cada uma das categorias do prêmio: * Contribuição com código no PostgreSQL; * Contribuição com código em ferramentas livres relacionadas ao PostgreSQL: * Pessoa que melhor contribuiu na lista pgbr-geral; * Melhor contribuição na organização da comunidade brasileira; * Melhor artigo técnico publicado nos últimos 2 anos. c) A indicação dos membros na primeira etapa deverá ser feita por esta lista, até o dia 08/09/2016; d) Os cinco nomes mais indicados na lista em cada categoria (caso exista tal quantidade), concorrerão ao prêmio na segunda etapa; e) Na segunda etapa, uma comissão avaliará as indicações e decidirá pelos vencedores em cada categoria até dia 16/09/2017 onde serão divulgados durante o encerramento do PGBR2017. No aguardo por críticas e sugestões. 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
Re: [pgbr-geral] Data de criação do usuário
Em 23 de agosto de 2017 11:39, Saulo Morais <sa...@abilityonline.com.br> escreveu: > > É possível saber a data de criação dos usuários? > > pg_user e pg_roles não possuem essas informações. > Nativamente não temos essa informação de Criação/Alteração de objetos... vc poderia implementar algo com Event Triggers [1], porém só funcionaria para objetos locais, os globais (usuarios, tablespaces, databases) ainda não são capturados por esse tipo de evento. Outra alternativa seria implementar uma hook na ProcessUtility para isso, mas é um pouco mais complicado. Att, [1] https://www.postgresql.org/docs/current/static/event-trigger-matrix.html -- 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
Re: [pgbr-geral] Remover drop database/table
Em 17 de agosto de 2017 14:21, Fábio Telles Rodriguez < fabio.tel...@gmail.com> escreveu: > > Em 17 de agosto de 2017 14:18, Tiago Brasil <neotbra...@gmail.com> escreveu: >> >> Não, é o inverso! >> >> Os dev vao poder criar objetos e esquemas, mas NÃO poderão dropar nada. > > > Aí você complica. Por padrão, quem cria um objeto é dono dele. E todo dono retem o poder de destruir o que criou. É um princípio básico que todo SGDB usa. Você tem duas alternativas: > > 1) Delegar outra pessoa para criar os objetos. > 2) Alterar o dono dos objetos depois que eles foram criados. > 3) utilizar Event Triggers [1] para "barrar" esse DROP . Att, [1] https://www.postgresql.org/docs/current/static/event-triggers.html -- 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
Re: [pgbr-geral] Arquivos temporários
Em 6 de julho de 2017 11:09, Ariel Alves <arielalves...@gmail.com> escreveu: > > Olá pessoal, > > Notei que na hora da criação de indexes o log registra essas linhas abaixo. > > > 2017-07-06 10:35:32.740 BRT assist dbname: LOG: arquivo temporário: caminho "base/pgsql_tmp/pgsql_tmp29413.2", tamanho 54045676 > 2017-07-06 10:35:32.854 BRT assist dbname: LOG: arquivo temporário: caminho "base/pgsql_tmp/pgsql_tmp29413.8", tamanho 7971156 > 2017-07-06 10:35:33.072 BRT assist dbname: LOG: arquivo temporário: caminho "base/pgsql_tmp/pgsql_tmp29413.6", tamanho 54000100 > 2017-07-06 10:35:33.394 BRT assist dbname: LOG: arquivo temporário: caminho "base/pgsql_tmp/pgsql_tmp29413.9", tamanho 8027496 > > > Queria saber qual parametro é responsavel por este arquivo temporário, work_mem, temp_buffers ou maintenance_work_mem. > > Creio que ajustando isso, o desempenho a criação desses idexes seria melhorado. > Vc precisa ajustar o "maintenance_work_mem" para tentar fazer com que o "sorting" realizado para criação do índice utilize apenas memória e não o disco (gerando esses arquivos temporários) para trabalhar. Dependendo da forma como vc executa esses CREATE INDEX vc pode setar ele na sessão, exemplo: SET maintenance_work_mem TO '1GB'; BEGIN; CREATE INDEX ... CREATE INDEX ... COMMIT; 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
Re: [pgbr-geral] Último ID antes do Commit [Resolvido]
Em 5 de julho de 2017 15:45, Sebastian Webber <sebast...@swebber.me> escreveu: > > Em 4 de julho de 2017 12:10, POWER Informática < power.informatica@gmail.com> escreveu: >> >> Achei nas minhas pesquisas essa dica, que é exatamente o que precisava fazer; >> >> >> >> BEGIN; >> >> INSERT INTO pedido(data) VALUES (now()); >> >> INSERT INTO item (fk_pedido, produto, quantidade, valor) >> VALUES (currval(‘pedido_numero_seq’), ‘Camiseta’, 2, 25.00); >> >> INSERT INTO item (fk_pedido, produto, quantidade, valor) >> VALUES (currval(‘pedido_numero_seq’),‘Calça’, 2, 40.70); >> >> INSERT INTO item (fk_pedido, produto, quantidade, valor) >> VALUES (currval(‘pedido_numero_seq’), ‘Meia’, 5, 5.90); >> >> INSERT INTO item (fk_pedido, produto, quantidade, valor) >> VALUES (currval(‘pedido_numero_seq’), ‘Camisa’, 1, 60.00); >> >> COMMIT; > > > Existe uma grande chance de isso não funcionar. > Porque nao??? Essa abordagem funciona sim e muito bem, porque o primeiro INSERT vai executar o NEXTVAL para setar o valor DEFAULT da chave primária da tabela "pedido" e se vc usar o CURRVAL dentro da mesma sessão ele irá retornar sim o valor corrente. A forma que o PostgreSQL implementa a dupla NEXTVAL e CURRVAL é justamente pra resolver esse tipo de problema. 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
Re: [pgbr-geral] backup com pg_probackup
Em 30 de junho de 2017 09:01, Douglas Fabiano Specht < douglasfabi...@gmail.com> escreveu: > > bom dia pessoal, > > alguem ja utilizou ou utiliza a ferramenta [1] para fazer os backups do postgres? > pelo que vi na documentação tanto o processo de fazer como o de restaurar em caso de desastre é bem mais simples que outras como o [2] e o [3]. > Eu não posso nem concordar e nem discordar com vc porque nunca usei [1]... mas tanto [2] quanto [3] são bem simples... Uma coisa que sempre observo nessas ferramentas é se o seu desenvolvimento está ativo, então se vc observar o github delas pode notar que [1] deve seu último commit em Mar/2017, já [2] há 3 dias atrás e [3] há 29 dias... Isso não quer dizer nada em relação a uma ser melhor que a outra e tal, mas acredito que software é algo quase que orgânico e que deve estar sempre em movimento. Att, [1] https://github.com/postgrespro/pg_probackup [2] http://www.pgbackrest.org/ [3] http://www.pgbarman.org/ -- 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
Re: [pgbr-geral] ERROR: out of shared memory in pg_dump
Em 29 de junho de 2017 18:00, Douglas Fabiano Specht < douglasfabi...@gmail.com> escreveu: > > > Fabrizio, > obrigado pela sua reposta > vou ajustar para 500, pois deu 432 o calculo e sei que esse banco pode ser acrescentado mais schemas.(42000/50+64) + 64 = 432 . Esqueci de mencionar que as "sequences" devem entrar no cálculo daquele "número de tabelas" porque elas internamente são uma tabela. > sobre sua duvida, hoje estamos fazendo dump como estrategia de backup, o que está errado..(eu ja li o otimo artigo do Telles) #1. Ok, mas como é a arquitetura desse seu database? Tipo cada schema seria como um "cliente" ou algo do gênero?? Porque se cada schema pode ser tratado isoladamente não teria porque vc fazer um dump de todo database em um único pg_dump, vc poderia fazer um script para ler os schemas e fazer dumps individuais por schema. Vc poderia usar os Syncronized Snapshots [1] também pra não precisar ficar fazendo esses ajustes e ter dados consistentes... obviamente que nao conheço seu modelo e não sei se os objetos nos schemas tem dependencias (FKs), então estou pensando em modelos com schemas isolados. > pretendo nos próximos dias implantar backup físico\logico. Ótimo > como estamos com 5 servidores de banco de dados, vc teria alguma ferramenta para recomendar que faça essa gerência de backup em vários servidores e uma maneira mais facil? > Para backup físico recomendo vc dar uma olhada no pgBackRest [2] ou o Barman [3]. Att, [1] https://www.postgresql.org/docs/9.5/static/functions-admin.html#FUNCTIONS-SNAPSHOT-SYNCHRONIZATION [2] http://www.pgbackrest.org/ [3] http://www.pgbarman.org/ -- 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
Re: [pgbr-geral] ERROR: out of shared memory in pg_dump
Em 29 de junho de 2017 11:35, Euler Taveira <eu...@timbira.com.br> escreveu: > > Em 28 de junho de 2017 22:35, Douglas Fabiano Specht < douglasfabi...@gmail.com> escreveu: >>> >>> >> Euler, >> esse valor é para cada schema 233 tabelas ou 41000 tabelas no geral de todos os schemas..? > > > É a quantidade de tabelas por execução do pg_dump. Então seria 181 schemas x 233 tabelas. > Não é *exatamente* este valor porque o PostgreSQL cria um hash na memória compartilhada (TopMemoryContext) para alocar esses locks e o tamanho dela é definido por: max_locks_per_transaction * (max_connections + max_prepared_transactions) Quero dizer com isso que não é necessário colocar no "max_locks_per_transaction" o valor da multplicação que o Euler comentou que é demasiado e ocupara memória compartilhada sem necessidade. Em um cenário como o seu que são muitas tabelas para efetuar dump poderi então fazer o seguinte cálculo: (numero_de_tabelas / (max_connections + max_prepared_transactions)) + 64 Desta forma quando rodar o dump vc terá slots suficientes para locks e também a folga de 64 para sua aplicacao continuar funcionando... porém eis que me surge uma dúvida?? - Vc precisa fazer um dump de TODOS schemas ao mesmo tempo??? 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
Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela
Em 28 de junho de 2017 22:57, Ronaldo Bernardes Pereira < ronaldobernar...@gmail.com> escreveu: > > ... [corte] ... > > > --=== Como acredito que você irá resolver seu problema, seque considerações > > O problema encontrado é que o PostgreSQL fez um CAST da coluna (gn) (Filter: ((gn)::text = '900'::text)) para atender o tipo de argumento da FUNCTION que era do tipo text e no caso a coluna que ele comparava era do tipo char. Como o tamanho do campo tipo text pode ser muito maior do que um campo tipo char, houve então o CAST implícito pelo PostgreSQL e com isso única alternativa que ele tinha nesse caso era fazer um seq scan, pois o índice não atendia para esse caso. > Show de bola Ronaldo... excelente análise e retorno... é por esse tipo de "cuidado" e "dedicação" sem compromisso que nunca deixo de acreditar em comunidades. Só por favor evite o top-posting. > --=== -->> Sugestões: > > 1 - Qual o tipo da coluna nfce_chave_acesso_fk e chave_acesso para entender melhor o problema? > > 2 - Colocar o tipo do argumento da FUNCTION com o mesmo tipo da coluna, para não ocorrer CAST implícito das colunas nfce_chave_acesso_fk ou chave_acesso > > 3 - Caso não tenha como mudar o tipo do argumento da FUNCTION, então realizar o CAST explicito na variável (chave) no corpo FUNCTION na linha ( PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;) > > Ex: PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave::bpchar; > > 4 - Executar e nos passar o resultado > > Ótimo... e pior é que esse tipo de equívoco é mais comum do que parece e nos passou totalmente desapercebido... porém lá no início da thread deveriamos ter mais informações como a estrutura das tabelas envolvidas então todos consideraram que os tipos de dados eram iguais e que outro problema deveria estar ocorrendo... mas novamente nós como "seres humanos" tendenciamos a complicar as coisas ao invés de simplificar. Se puder depois @Alexsander dar um feedback, caso a sugestão do Ronaldo ajudou para ai termos um bom histórico na nossa lista de discussão para consultas futuras. 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
Re: [pgbr-geral] Como descobrir as dependência de uma function/view no Postgresql 9.2?
Em 27 de junho de 2017 09:14, Celso - Gmail <clorenzett...@gmail.com> escreveu: > > Bom dia senhores, > > Estou tentando descobrir na pg_depend as dependências entre os objetos do banco de dados. > O objetivo é exportar eles na ordem correta que devem ser criados/atualizados em outro banco de dados. > Imagino que em algum lugar deva existir essa informação, visto que o pg_dump/pg_restore faz isso. > > Ou exista outro caminho para chegar neste objetivo. > > Abaixo criei 3 objetos simples para exemplicar e facilitar que puder ajudar. > > CREATE OR REPLACE VIEW vw_teste AS SELECT 1 AS emp_empresa; > CREATE OR REPLACE VIEW vw_teste_2 AS SELECT emp_empresa FROM vw_teste; > > CREATE OR REPLACE FUNCTION fc_empresa() RETURNS INTEGER AS > $BODY$ >SELECT emp_empresa FROM vw_teste; > $BODY$ > LANGUAGE sql; > > O SQL abaixo retorna apenas o Schema como dependência e “deveria” retornar a vw_teste também. > > SELECT * FROM pg_depend where objid in (select oid from pg_class where relname = 'vw_teste_2'); > Essa informação de "dependência" entre os objetos é armazenada na tabela "pg_depend" [1] do catálogo. No wiki [2] tem uns exemplos de como usar ela para mostrar dependências entre objetos. Att, [1] https://www.postgresql.org/docs/current/static/catalog-pg-depend.html [2] https://wiki.postgresql.org/wiki/Pg_depend_display -- 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
Re: [pgbr-geral] SQL Select
Em 22 de junho de 2017 15:36, Arthur Nascimento <tur...@gmail.com> escreveu: > > On Thu, Jun 22, 2017 at 3:10 PM Ricardo <rica...@longomaquinas.com> wrote: > > Estou quebrando a cabeça aqui pra criar um select que calcule o Resultado de entrada e saída da tabela abaixo sem tem que criar uma função. Será possível ? > > Sim, com uma window function: > > #select teste.*, sum(v_entrada) over w - sum(v_saida) over w from teste window w as (partition by teste.mes); > tipo | mes | v_entrada | v_saida | ?column? > --+-+---+-+-- > E| 1 | 100 | 0 | -100 > S| 1 | 0 | 200 | -100 > E| 2 | 150 | 0 | -80 > S| 2 | 0 | 230 | -80 > E| 3 | 200 | 0 | 200 > S| 3 | 0 | 0 | 200 > (6 rows) > > > Essa apresentação sobre window functions do Bruce Momjian é uma leitura adicional muito boa: https://momjian.us/main/writings/pgsql/window.pdf > Aproveitando e o gancho e fazendo um pouco de propaganda, o Bruco Momjian irá palestrar dia 11/07/2017 justamente sobre "Window Functions" na PGConf.Brasil [1] que é um evento PostgreSQL "online" e "gratuito". Se inscrevam lá. Att, [1] http://www.pgconf.com.br/#palestrantes -- 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
Re: [pgbr-geral] Calculo de memoria com 2 instancias
2017-06-21 19:55 GMT-03:00 Douglas Fabiano Specht <douglasfabi...@gmail.com >: > > Boa noite Pessoal, > hoje a tarde tivemos uma queda do serviço do postgres e gostaria de uma opinião de vcs > temos um servidor debian com 15GB de memória na AWS rodando com 2 instancias do Postgres. > instancia 1 > PG 9.6 porta 5432 > max_conections: 1000 > sistema OLTP com conexão persistente > > instancia 2 > PG 9.5 porta 5433 > max_connection: 80 > sistema web > > Qual o calculo que poderia utilizar para cada instancia considerando os dados acima nas configurações do postgres? > > Gostaria de saber se alguém tem em um mesmo servidor 2 serviços do postgres separados e se poderia passar alguma dica. > > Verificamos no log do SO que o mesmo finalizou o processo da instancia 2 por alto consumo de memória > > > Erro no log do postgresql: > 2017-06-21 16:15:34 BRT [9969]: [1-1] user=portalbi,db=portalbi,app=[unknown],client=192.168.10.8 WARNING: terminating connection because of crash of another server process > 2017-06-21 16:15:41 BRT [30133]: [21-1] user=,db=,app=,client= LOG: all server processes terminated; reinitializing > 2017-06-21 16:15:41 BRT [30133]: [22-1] user=,db=,app=,client= FATAL: could not map anonymous shared memory: Cannot allocate memory > 2017-06-21 16:15:41 BRT [30133]: [23-1] user=,db=,app=,client= HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 6640975872 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections. > Tem área de swap configurada nesse seu servidor? Como estão seus parâmetros do kernel: - vm.overcommit_memory - vm.overcommit_ratio - vm.swappiness 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
Re: [pgbr-geral] Agrupar bancos de dados replicado num único Banco
Em 22 de junho de 2017 02:18, Ivanelson Nunes <ivanelsonnu...@gmail.com> escreveu: > > Eu tenho no modelo uma coluna empresa em todas as tabelas. Então qual caminho seguir pglogical? > Bucardo? > BDR? > Vc não respondeu a pergunta do Euler, sua chave primária é única em cada base de dados? Essa coluna empresa faz parte da sua PK... se não nos mostrar um pouco mais do modelo fica dificil entender. Vide meu outro email com outra alternativa caso vc não tenha PK única. 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
Re: [pgbr-geral] Agrupar bancos de dados replicado num único Banco
Em 21 de junho de 2017 19:35, Euler Taveira <eu...@timbira.com.br> escreveu: > > Em 21 de junho de 2017 18:37, Ivanelson Nunes <ivanelsonnu...@gmail.com> escreveu: >> >> >> São todos iguais... Em todos os BD's de origem é o mesmo nome de esquema, mesmas tabelas, mesmas colunas, etc > > > Você só vai conseguir agregar dados de diferentes origens se a identificação da tupla (geralmente a chave) for única para todas as lojas. Isso quer dizer que você terá que (i) ter id único para registro na tabela contrato de todas as lojas ou (ii) ter uma coluna adicional "loja" em cada tabela a ser replicada para permitir uma identificação única dos registros. Tudo isso quer dizer que o seu modelo de dados deve estar preparado para essa agregação de múltiplas fontes de dados. > > Outra alternativa seria cada loja ter o "seu" schema, tipo "loja1", "loja2", "loja3", ..., "loja200"... assim os objetos seriam diferentes, e na "matriz" outro schema também... isso é fácil ajustando adequadamente o "search_path" em cada instância para deixar transparente para a aplicação pois provavelmente ela não qualifica o schema... ou qualifica ao usar em SQL Ivanelson?? Nesta base central em um outro esquema especial, tipo "agregador" poderia criar toda a estrutura e por herança cada tabela de cada esquema herdar teste, algo do tipo: CREATE SCHEMA agregador; CREATE SCHEMA matriz; CREATE SCHEMA loja1; CREATE SCHEMA loja2; CREATE TABLE agregador.contrato(...); CREATE TABLE matriz.contrato(..) INHERITS (agregador.contrato); CREATE TABLE loja1.contrato(..) INHERITS (agregador.contrato); CREATE TABLE loja2.contrato(..) INHERITS (agregador.contrato); Desta forma temos os dados isolados por esquema e, caso necessário, também todos dados em um único ponto no esquema "agregador". Meus 0.01 centavos! 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
Re: [pgbr-geral] Agrupar bancos de dados replicado num único Banco
Em 21 de junho de 2017 18:11, Ivanelson Nunes <ivanelsonnu...@gmail.com> escreveu: > > > Em 21 de junho de 2017 18:01, Euler Taveira <eu...@timbira.com.br> escreveu: >> >> A consolidação em um mesmo banco de dados só vai funcionar se na origem houver nomes de esquemas distintos (geralmente as aplicações usam o mesmo nome). > > > Euler, > > Fiquei confuso nessa parte! Tipo eu então minha Loja1, Loja2, ...Loja200 e nessas lojas tenho meu BD com seu esquema, etc... Então quero trazer esses dados para um "BD-GERAL" remoto que fica no meu datacenter, porem nesse "BD-GERAL" deve possibilitar a junção de todos esses dados. > > Por exemplo, eu tenho a tabela "CONTRATO", então nesse BD-GERAL eu quero enxergar/selecionar num select os CONTRATOS da Loja1, Loja2,...Loja200 e assim seria com as demais tabelas. > Qual a confusão? O Euler falou exatamente a restrição de que o "esquema"."tabela" de cada database precisa ser IGUAL na ORIGEM e DESTINO... vc tem em cada database "esquemas" distintos para poder distinguir, por exemplo, a tabela "contrato" de cada Loja?? 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
Re: [pgbr-geral] utilizar copy na maquina Local
Em 19 de junho de 2017 11:11, Douglas Fabiano Specht < douglasfabi...@gmail.com> escreveu: > > Em 19 de junho de 2017 10:58, Flavio Henrique Araque Gurgel < fha...@gmail.com> escreveu: >> >> Em seg, 19 de jun de 2017 15:53, Douglas Fabiano Specht < douglasfabi...@gmail.com> escreveu: >>> >>> bom dia pessoal, >>> preciso utilizar o copy para gerar um csv, ocorre que o comando irá ser executado em uma maquina que não é o servidor, e preciso salvar o resultado que é o arquivo csv na maquina cliente. >>> alguém ja precisou disso ou usou algo diferente do copy para exportar local nao no servidor? >>> utilizo postgres 9.5 e servidor linux, a maquina cliente é windows 7 >> >> Você pode usar o \copy do psql. > > > Obrigado pela resposta Gurgel, > como eu poderia utilizar dentro de uma function o \copy? isso seria possível? Douglas, O \copy é um "meta-comando" do psql [1] e você não consegue utilizar ele dentro de uma PL. Para utlizar o COPY para exportar dados em formato CSV no seu "client" vc terá que utilizar a implementação do protocolo do COPY na sua linguagem de programação (se ela suportar ela claro). Att, [1] https://www.postgresql.org/docs/current/static/app-psql.html#APP-PSQL-META-COMMANDS-COPY -- 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
Re: [pgbr-geral] unsubscrib
Em 2 de junho de 2017 16:44, Silfar Goulart <sil...@gmail.com> escreveu: > > > Silfar Goulart > Boa tarde Silfar, Para vc se "desinscrever" desta lista precisa acessar o link [1] e no final da página informar seu email clicar no botão "Desincrever-se ou editar opções". Att, [1] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- 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
Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela
Em 2 de junho de 2017 12:32, Alexsander Rosa <alexsander.r...@gmail.com>
escreveu:
>
> 2017-06-02 11:50 GMT-03:00 Flavio Henrique Araque Gurgel <fha...@gmail.com
>:
>>
>> Para de bagunça a lista, pelamor.
>> A gente responde LÁ EMBAIXO ! olha só:
>
>
> Coloquei STABLE e não mudou nada:
> EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
sp_teste('4317060556386800011365701004061895261728');
> QUERY PLAN
>
--
> Result (cost=0.00..0.26 rows=1 width=0) (actual time=1478.944..1478.944
rows=1 loops=1)
>Buffers: shared hit=18731 read=123491
> Total runtime: 1478.955 ms
> (3 rows)
>
Roda o ajuste abaixo (além do STABLE) e roda novamente o teste:
ALTER FUNCTION sp_teste(text) COST 10;
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
Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela
Em 2 de junho de 2017 10:46, Alexsander Rosa <alexsander.r...@gmail.com>
escreveu:
>
> A tabela tem cerca de 1 Gb:
> SELECT pg_size_pretty(pg_relation_size('cf_cupom'));
> pg_size_pretty
>
> 1114 MB
> (1 registro)
>
> Existe um índice UNIQUE no campo utilizado na query:
> "idx_cupom_chave" UNIQUE, btree (nfce_chave_acesso_fk) WHERE
nfce_chave_acesso_fk IS NOT NULL
>
> O campo utilizado também é FOREIGN KEY:
> "cupom_chave_nfe_fkey" FOREIGN KEY (nfce_chave_acesso_fk) REFERENCES
nfe_xml(chave_acesso) DEFERRABLE
>
> Código da procedure de teste:
> CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
> RETURNS text
> LANGUAGE plpgsql
> AS $function$
> DECLARE
> BEGIN
> RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
> -- EXECUTE 'SELECT cod_empresa_fk FROM cf_cupom WHERE
nfce_chave_acesso_fk = $1' INTO empcupom USING chave;
> PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
> RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
> -- demora 1617 ms
>
> PERFORM chave_acesso from nfe_xml where chave_acesso = chave;
> RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
> -- demora 21 ms
>
> Return 'OK';
> END;
> $function$
> ;
>
> Comparativo:
> select sp_teste('4317060556386800011365701004061895261728');
> -- demora 1630 ms
>
> select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
'4317060556386800011365701004061895261728';
> -- demora 11 ms
>
> Foi feito um VACUUM FULL ANALYZE na tabela.
> Alguém tem alguma dica para ajudar em nossa investigação?
>
Faz o seguinte, remove aqueles "RAISE NOTICE" da sua PL e roda no psql com
o "\timing on"...
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
Re: [pgbr-geral] Reiniciar sequence diariamente
Em 27 de maio de 2017 15:33, Neto pr <neto...@gmail.com> escreveu: > Ola pessoal > preciso que uma sequence seja zerada todos os dias, ou seja, que o campo > - start with receba zero. > Crontab? 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
Re: [pgbr-geral] Senhores como alterar o e-mail de contato com a lista
Em 23 de maio de 2017 13:50, <j...@inbraco.com> escreveu: > > Boa tarde > > Senhores como altero o e-mail que uso para contatar com a lista > Basta acessar [1] e no final da página informar seu email e clicar no botão "Desinscrever-se ou editar opções". Att, [1] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- 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
Re: [pgbr-geral] PgDay em Curitiba no 9o. FTSL
Em 22 de maio de 2017 10:27, Alisson Coelho de Morais < coelhotopet...@gmail.com> escreveu: > Olá Pessoal, > a comunidade tem interesse em fazer um PgDay dentro do Fórum de Tecnologia > em Software Livre que acontecerá de 27 a 29 de setembro? > No aguardo, > > Bom dia Alisson, PGDays são sempre muito bem vindos, porém será que não vais gerar certa "concorrência" com o evento nacional (PGBR) que irá ocorrer em Setembro também? https://pgbr.postgresql.org.br/2017/ 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
Re: [pgbr-geral] Espaço em disco após update = null
Em 27 de abril de 2017 03:55, Flavio Henrique Araque Gurgel < fha...@gmail.com> escreveu: >> >> >> É um sistema online com 30 mil usuários, ou seja, não tem como eu ter downtime. Eu entendo que não há como fazer isso sem ter um downtime, pois qualquer coisa que eu faça eu irei precisar de um exclusive lock naquela tabela e, o usuário, não consegue nem logar se não tiver acesso à ela. >> >> Mas de qualquer forma eu provavelmente irei escolher a opção do pg_dump. Pois para eu fazer tanto o vacuum full quanto o CREATE TABLE AS, irei precisar ter mais espaço em disco e pra isso vou ter que por o sistema 2x offline, uma para incluir mais espaço e outra para rodar os comandos. >> >> A tabela tem 4TB, complicando ainda mais minha vida. > > > Sim, mas isso é contando sua coluna bytea que vai desaparecer. > Portanto, a solução de criar uma tabela como disse o Euler pode ser vantajosa, pois a nova tabela não terá o tamanho da original e será bem menor. > > Você pode fazer isso "a quente" e ter um corte de serviço bem rápido só pra inserir as novas linhas desde a criação e remover a antiga tabela gigante, o que provavelmente levará poucos minutos e, dependendo do sistema, poderá até trabalhar sem as linhas ausentes até que você as insira, ou seja, você pode fazer tudo com um downtime bem bem pequeno. > Outra opção pra esse cenário seria rodar aquele UPDATE e após isso um pg_repack [1] para eliminar o inchaço *sem* o downtime de um vacuum full ou de algum script para recriar a tabela. Att, [1] http://reorg.github.io/pg_repack/ -- 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
Re: [pgbr-geral] Espaço em disco após update = null
Em 26 de abril de 2017 23:54, Euler Taveira <eu...@timbira.com.br> escreveu: > > Em 26 de abril de 2017 23:40, Patrick B <patrickbake...@gmail.com> escreveu: >> >> >> Se eu fizer um basebackup do meu servidor e restaurar num novo, também funcionaria? > > Não. Você estará transportando o inchaço de um lugar para outro. Uma possibilidade seria > renomear a tabela atual, fazer CREATE TABLE foo AS SELECT a, b, NULL as campobytea > FROM bar (as restrições devem ser criadas também) e depois que tudo estiver certo fazer > um DROP TABLE na tabela original. Isso irá evitar o inchaço. > É uma alternativa, mas se o OP tem janela de manutenção e, *dependendo* do modelo de dados, será mais fácil ele realizar o UPDATE que mencionou seguido de um VACUUM FULL que irá reescrever todos datafiles. 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
Re: [pgbr-geral] Recuperar Base PostgreSQL pasta data
Em 24 de abril de 2017 11:06, Edson F. Lidorio <ed...@openmailbox.org> escreveu: > > Fabrízio bom dia, > > Para Debian, precisa também fazer alguma configuração adicional? > Com relação a SELinux? -- 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
Re: [pgbr-geral] Recuperar Base PostgreSQL pasta data
Em 24 de abril de 2017 08:23, Edson F. Lidorio <ed...@openmailbox.org> escreveu: > > O problema, era o selinux do CentOS, desabilitei o selinux e apliquei as pemissões novamente e o PostgreSQL iniciou normalmente. > > Comandos usados: > # sudo /usr/sbin/setenforce 0 > # sudo chown postgres /var/lib/pgsql/9.6/ > # sudo chown postgres:postgres /var/lib/pgsql/9.6/data > # chmod 700 /var/lib/pgsql/9.6/ > # sudo systemctl start postgresql-9.6 > > Observação: Pesquisando no google, percebi que tem mais pessoa com esse problema. É um problema com CentOS e PostgreSQL, que não se dao muito bem. > Também já fiz isso inúmeras vezes, porém acredito que o correto seria configurar adequadamente o SELinux conforme um pequeno exemplo na doc do RHEL [1]. Att, [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/sect-Managing_Confined_Services-PostgreSQL-Configuration_Examples.html -- 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
Re: [pgbr-geral] Database is in recovery mode
Em 24 de abril de 2017 08:53, Daniel Luiz da Silva <daniel.si...@ipm.com.br> escreveu: > Bom dia, > Fabrízio, > > Acho esse assunto muito interessante, se houvesse um treinamento na > Timbira sobre essa relação do Postgres com memória linux internamente, ou > seja, calcular no momento como está o buffer cache, shared memory e média > de overcommit, explorando melhor o arquivo vminfo do linux, eu aderia. > Obrigado por responder esses tipos de tópicos sempre me ajuda bastante. > > Bom dia Daniel, Que bom que ajudo de alguma forma... assim estamos então cumprindo nosso papel enquanto comunidade... Falando sobre a Timbira, já possuímos treinamento OnLine de Tuning do PostgreSQL [1] onde em uma parte do mesmo abordamos justamente do Sistema Operacional, que no caso deste treinamento é o Linux (ainda não temos preparado para Windows). Se tiver mais dúvidas sobre a timbira podes entrar em contato via comerc...@timbira.com.br. Att, [1] https://www.sympla.com.br/postgresql-tuning__115174 -- 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
Re: [pgbr-geral] Database is in recovery mode
Em 20 de abril de 2017 17:55, Tiago José Adami <adam...@gmail.com> escreveu: > > > > > Nem preciso te dizer que deves atualizar pra 9.4.11... > > Sabia que a primeira coisa que me diriam seria para atualizar ;) > > E concordo plenamente, mas a instalação é do repositório oficial da > Amazon que está desatualizado. Por enquanto uma GMUD para incluir > outro repo ainda não foi discutida. > Faz parte... > >> (...) > >> WARNING,57P02,"terminating connection because of crash of another > >> server process","The postmaster has commanded this server process to > >> roll back the current transaction and exit, because another server > >> process exited abnormally and possibly corrupted shared memory.","In a > >> moment you should be able to reconnect to the database and repeat your > >> command." > >> (...) > > > > Só tem essa informação no LOG?? Essa informação que vc pegou não é a causa e > > sim o efeito... vasculhe seu log por mais informações. > > Estou vasculhando pela 3a vez os logs, mas não há nenhuma informação > adicional. Estas mensagens ocorre logo após a execução de um SQL > SELECT qualquer. > Isso é sintoma mesmo de OOMKiller como o colega Felipe mencionou anteriormente. > > > > Eu arrisco que vc pode estar passando por algum "overcommit_memory" ou coisa > > parecida. Esse linux tem swap e como está o overcommit_memory? > > O OOM e overcommit estão com os valores padrão > > vm.oom_dump_tasks = 1 > vm.oom_kill_allocating_task = 0 > vm.overcommit_kbytes = 0 > vm.overcommit_memory = 0 > vm.overcommit_ratio = 50 > Bingo... > O servidor não tem Swap. > Vejo que não é esse seu problema, mas não custaria nada ter uma área de swap para alguma emergência. > Estava quase enviando o e-mail quando fui checar novamente o > /var/log/messages. Agradeço também ao colega Felipe Pereira (obrigado > pelas dicas), desta vez encontrei a causa mortis: > > Apr 20 18:00:47 ip-172-16-4-27 kernel: [238117.075735] Killed process > 2485 (postmaster) total-vm:2124064kB, anon-rss:272232kB, file-rss:4kB, > shmem-rss:1588240kB > Bingo... > A questão é: mesmo tendo uma quantidade de memória livre que fica > sempre entre 3 e 4 GB (livre, o resto é cache + usada), como isso pode > estar acontecendo? > Isso é por conta do "overcommit_ratio = 50" que indica que foi solicitado alocar mais memória que o "total de swap + 50% da RAM" [1] ... como vc nao tem swap entao ele tentou alocar mais que RAM/2 e o kernel matou... Att, [1] https://www.kernel.org/doc/Documentation/vm/overcommit-accounting -- 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
Re: [pgbr-geral] Database is in recovery mode
Em 20 de abril de 2017 15:35, Tiago José Adami <adam...@gmail.com> escreveu: > > Boa tarde a todos. > > Tenho um servidor na Amazon com PostgreSQL 9.4.9 64-bit instalado, lá > roda uma versão do Fedora modificada. > Nem preciso te dizer que deves atualizar pra 9.4.11... > Há 16 GB de memória RAM. > > max_connections=300 > shared_buffers=2GB > work_mem=4MB > > De uns tempos para cá, após configurar o backup com arquivamento de > logs está ocorrendo este erro sem muita razão aparente. Sempre ocorre > depois de algum SQL SELECT (não necessariamente o mesmo e dificilmente > usando as mesmas tabelas, já verifiquei isso). > > (...) > WARNING,57P02,"terminating connection because of crash of another > server process","The postmaster has commanded this server process to > roll back the current transaction and exit, because another server > process exited abnormally and possibly corrupted shared memory.","In a > moment you should be able to reconnect to the database and repeat your > command." > (...) > Só tem essa informação no LOG?? Essa informação que vc pegou não é a causa e sim o efeito... vasculhe seu log por mais informações. > A aplicação recebe uma mensagem "Database is in recovery mode". Dura 2 > ou 3 segundos e volta ao normal. > Esse é o comportamento normal... > Nas minhas pesquisas e até onde vai meu conhecimento isto ocorre com > problemas de hardware, em especial, memórias (lembro-me do tempo do > PostgreSQL 7.4 rodando em servidores com pentes de memória de > velocidade e latências diferentes). > > Mas levando em consideração que o servidor está na Amazon... o que > mais poderia estar causando este erro? Algum palpite? > Eu arrisco que vc pode estar passando por algum "overcommit_memory" ou coisa parecida. Esse linux tem swap e como está o overcommit_memory? 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
Re: [pgbr-geral] MeetUp "Bate-papo sobre PostgreSQL" - 2ndQuadrant
2017-03-07 15:24 GMT-03:00 William Ivanski <william.ivan...@gmail.com>: > > Agradeço a sugestão, Fabrizio! > > Eu não sei se podemos fazer isso. PgDays normalmente são organizados pela comunidade oficial do PostgreSQL Brasil ou da região. > Ué por acaso vc não se considera um membro da comunidade? > Outro ponto, não é um evento de um dia inteiro, é somente à noite, das 19h às 21h. Poderia ser PgNight, talvez, rss > Quanto a turno e/ou período de tempo creio que não seja um problema... agora até fiquei em dúvida em relação a isso, porque poderiamos estabelecer entao: - PGBR (evento nacional mais de um dia) - PGDay (evento local um dia inteiro) - Meetups (evento local um turno) <-- aqui está seu evento Idéias/Críticas/Sugestões?? 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
Re: [pgbr-geral] MeetUp "Bate-papo sobre PostgreSQL" - 2ndQuadrant
2017-03-07 14:36 GMT-03:00 William Ivanski <william.ivan...@gmail.com>: > > https://www.facebook.com/events/1291506420931048/ > > Data: 16/03/2017 às 19:00 horas > Local: Funpar - Sala 05 - R. João Negrão, 280, Centro, Curitiba - PR > > Agenda: > - Disaster Recovery com Barman 2 > - PostgreSQL no Raspberry Pi > - OmniDB: uma ferramenta web para gerenciamento e conversão de bancos de dados > > Palestrantes: Rubens Souza (2ndQuadrant Itália), Rafael Castro, William Ivanski > > Entrada Franca > Show de bola a iniciativa, mas porque não nomear o encontro como um PDay ?? 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
Re: [pgbr-geral] alerta de tentativas de conexão
On 02-03-2017 09:56, Alessandro Lima wrote: > Bom dia, > > Gostaria de saber se existe alguma ferramenta para alertar/monitorar > tentativas (ataques) de conexão ao banco de dados. > O PostgreSQL não implementa isso, porém vc mesmo pode implementar isso de forma elegante criando uma extensão usando _hooks_ [1], em especial o _ClientAuthentication_hook_type_ que está disponível apartir da 9.1. Com esse _hook_ vc consegue desviar a autenticação e implementar o seu código, por exemplo esse controle de número de tentativas de uma mesma origem em um curto espaço de tempo. Um exemplo de uso desse _hook_ é a extensão que vem com o PostgreSQL chamada _auth_delay_ [2] que tem um código bem simples [3] Att, [1] https://wiki.postgresql.org/images/e/e3/Hooks_in_postgresql.pdf [2] https://www.postgresql.org/docs/current/static/auth-delay.html [3] https://doxygen.postgresql.org/auth__delay_8c_source.html -- 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
Re: [pgbr-geral] setar fsync na sessao
On 31-01-2017 17:35, Douglas Fabiano Specht wrote: > pessoal, > tenho uma leitura bem intensa que efetua um insert com muitos dados em > uma temp table. > estava lendo para setar o FSYNC=off para agilizar o processo, mas > gostaria de saber se isso é possível somente na sessão que estou ou irá > afetar todas as conexões? > Não, a GUC fsync não pode ser definida "por sessão"... eu também não recomendaria o seu uso pois ela desligada pode levar a corrupção de dados em caso de alguma falha. Você pode usar o "synchronous_commit = off" na sua sessão, o que ajuda em operações intensas de escrita. 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
[pgbr-geral] Paper "The Design of Postgres"
Pessoal, Para quem se interessar vejam um paper antigo da University of Califórnia entitulado "The Desing of Postgres" [1]. Interessante saber um pouco das nossas origens... Att, [1] http://db.cs.berkeley.edu/papers/ERL-M85-95.pdf -- 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
Re: [pgbr-geral] VACUUM FULL
On 26-01-2017 12:19, Danilo Silva wrote: > Pessoal, > > Atualmente utilizo a versão 9.3 com replicação nativa para um escravo, > fazendo cópia dos archives para o escravo + servidor de backup. > > Como podemos identificar a necessidade ou não de rodar um VACUUM FULL? > Se vc der uma pesquisada no histórico [1] desta lista irá encontrar diversas discussões a respeito de como detectar inchaço de objetos > Como teste, rodei o VACUUM FULL apenas em uma tabela de 700mb e o > diretório pg_xlog cresceu 400mb a mais e levou um tempo para ser > liberado esse espaço adicional, esse comportamento é normal? > Sim. O VACUUM FULL reescreve os datafiles da sua tabela (heap + toast + indexes), e isso quer dizer que ele faz "literalmente" uma cópia física dos datafiles, ou seja, ele consome espaço em disco além do já utilizado pelos datafiles atuais. E além dos datafiles como qualquer operação transacional normal do PostgreSQL (com exceção de Unlogged Tables) ele além de reescrever os datafiles também escreve os logs de transações (diretório xlog). Ele é implementado desta forma porque precisa garantir as características "Atomicidade" e "Durabilidade" do ACID através das técnicas de Write-ahead Logging [2]. E como os wal files são gerados (pg_xlog) a replicação física poderá se beneficiar pois usa os registros dos logs de transação para aplicar a mudança nas páginas também no(s) slave(s). > Em média, quanto tempo leva para o espaço em disco ocupado pelo VACUUM > FULL ser liberado? > Difícil mensurar isso porque, por exemplo, seu servidor pode estar retendo wal files porque seu procedimento de archive pode estar demorando por latência de rede ou algo do gênero. Com archive_mode ligado e o archive_command devidamente configurado o PostgreSQL só irá reciclar o wal (remover segmentos antigos do pg_xlog) quando o arquivamento for bem sucedido. Entao se vc faz um "scp" ou "rsync", por exemplo, o sinal de que o segmento foi copiado com sucesso para outro local só será enviado ao PostgreSQL após o comando ser executado. Note que eu apenas "imaginei" um cenário baseado nas informações que você forneceu, mas existem outras variáveis a considerar. Att, [1] https://www.postgresql.org.br/historico [2] https://en.wikipedia.org/wiki/Write-ahead_logging -- 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
Re: [pgbr-geral] Sincronismo de tabela
On 20-01-2017 15:31, Pedro B. Alves wrote: > > * Dae pessoal. > > Não sei se seria nesse fórum para essa duvida mas vamos lá.. > > Eu tenho uma tabela no meu banco de dados da empresa tabela de Parâmetros. > > que queria que fosse sincronizado com as bases dos meus clientes. > > tipo, cadastro o um parametro novo na nossa base e gostaria que fosse > para a tabela de nossos clientes também.. > E na base do seu cliente essa tabela também sofrerá alterações? > alguém tem alguma ideia de qual a melhor forma de fazer isso? > Existem algumas ferramentas/soluções para essa atividade como o pglogical [1] ou Slony [2]. Cada uma delas tem algumas restrições bem como vantagens e desvantagens. > sabendo que temos bastante registros nessa tabela. > A quantidade de registros que importa em uma replicação geralmente não é o total da tabela, e sim o volume de alterações (deltas) que a mesma sofre. Se vc tiver uma tabela com milhoes de registro que quase nao sofre alteração apenas o setup inicial da replicação sera demorado. 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
Re: [pgbr-geral] Sequence Jump 32
On 16-01-2017 23:25, Euler Taveira wrote: > On 16-01-2017 16:01, Jonas Teixeira de Freitas wrote: >> https://listas.postgresql.org.br/pipermail/pgbr-geral/2010-April/020556.html >> >> Para o antigo problema de sequence pular 32 registros *log_cnt, * alguém >> conseguiu alguma solução? >> > Além da discussão citada, também comentei em [1] e na -hackers houve uma > discussão [2] também. > > Em resumo, é aquilo que o Dutra havia comentado: sequências foram > projetadas para terem "buracos". O fato de haver esse "buraco" de até 32 > números, é um detalhe de implementação para otimizar a escrita no WAL. > Exatamente... as Sequences no PostgreSQL foram projetadas para NUNCA conflitar e não seguir uma série sem falhas (sua necessidade de negócio). Então se sua necessidade de negócio é uma série sem falhas talvez o objeto SEQUENCE não seja o ideal. >> Alguma forma de conseguir controlar a sequence para evitar que ocorra >> esse salto de numeração. >> > Não tem como controlar esse número em tempo de compilação ou a partir da > configuração. A única maneira é alterar SEQ_LOG_VALS em sequence.c. > Pode até ser mas isso pode levar a problemas de performance, veja o comentário no código: 46 /* 47 * We don't want to log each fetching of a value from a sequence, 48 * so we pre-log a few fetches in advance. In the event of 49 * crash we can lose (skip over) as many values as we pre-logged. 50 */ 51 #define SEQ_LOG_VALS32 Sem contar que será necessário gerar um "fork" do PostgreSQL e necessário empacotar e distribuir a sua versão do PostgreSQL com esse "pequeno" ajuste. Se me perguntar "dá pra fazer" eu responderei que sim, mas será que vale a pena? > Por fim, não parece o serviço de maneira inadequada (kill -9, -m > immediate, ...) que você não terá problemas com isso. > Com certeza... parar o serviço do PostgreSQL conforme o Euler descreveu vc terá esse comportamento anormal e também em casos de crash no servidor seja por qual motivo for. > Não, isso definitivamente não é um bug. > Exato, é um comportamento normal do PostgreSQL conforme demonstrei no post citado pelo Jonas. Existem algumas alternativas para implementar uma sequence "gapless" no PostgreSQL, veja: https://gist.github.com/fabriziomello/5cfff0541cd34e157ead545d815c2194 http://www.varlena.com/GeneralBits/130.php Entretanto existe um patch que está "parado" que tem a intenção de implementar o "Sequence Access Method" [1] onde uma implementação como extensão é justamente o "Gapless Sequence" que irá atender esses requisitos de negócio. Participei como revisor do código mas ainda tem alguns problemas de design e o mesmo não foi pra frente. Ainda não vi nada novo do autor para a versão 10. Att, [1] https://commitfest.postgresql.org/9/466/ -- 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
Re: [pgbr-geral] Before Delete !
On 29-11-2016 18:20, Agape World Informática Ltda wrote: > Boa Noite. > > Preciso fazer uma condicao em uma trigger para que o usuario > Não consiga deletar alguns registros. > > Alguem sabe o procedimento. > Uso Postgres 9.3. > > > Tipo : > > If old.idcodigo < 10 then >--não delete o registros. > Return old. > Use "RETURN NULL" pra desconsiderar as alterações efetuadas pela trigger. 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
Re: [pgbr-geral] PgTune x PGConfig Opiniões
On 25-11-2016 15:47, Eduardo Az - EMBRASIS wrote: > Pessoal, boa tarde > > Gostaria de opiniões, boas ou ruins, dos experts no PG. > > Tenho usado estas 2 "páginas", que sugerem configurações pro banco > (atualmente, mais a 1). > > 1) http://www.pgconfig.org > > 2) http://pgtune.leopard.in.ua > > São realmente boas? As configurações mostradas tem coerência? > > Eu uso seguindo o principio que é melhor usar do que deixar no > "standard", apesar das minhas bases serem bem pequenas (a maior +- > 500MB), em comparação ao que seria uma base "de respeito". > Eduardo, Ambas ferramentas são boas, e na maioria dos cenários é melhor utilizar a configuração gerada por ela do que a padrão do PostgreSQL, que apesar de ter "evoluido" em alguns pontos, ainda é conservadora. BTW prefiro o pgconfig.org porque além de conhecer o autor (nosso colega Sebastian), também acredito que esteja bem mais atualizada do que outras. 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
Re: [pgbr-geral] Tabela Percentual alto de Tuplas marcadas como Delete
On 28-11-2016 09:16, Fernando Franquini 'capin' wrote: > > O autovacuum deveria fazer isso pra você. VACUUM FULL é uma operação > custosa para tabelas grandes e a tabela fica bloqueada durante toda > a execução. > Seu autovacuum está ligado ? > Faça : > SHOW autovaccum; > Pode ser que seu dba anterior tenha deixado desligado por algum motivo. > > > Sim, está desligado por opção, pois chegaram a conclusão que o > AUTOVACUUM durante o dia atrapalha (devido o tamanho das tabelas - Mas > ainda quero realizar uma alteração a acompanhar isso um dia), por isso é > feito VACUUM em algumas tabelas principais durante a noite (porque é > mais rápido) e VACUUM FULL no final de semana, sim, temos essa janela. > Esse é um equivoco comum... desligar o autovacuum é, na maioria dos cenários, pior do que manter ligado. Dê uma lida nesse post da CitusData que nosso colega Sebastian gentilmente traduziu para pt-br [1]. Vc precisa entender que tabelas que geram muitas tuplas mortas (por DELETE/UPDATE ou INSERT cancelado) o autovacuum deve ser mais agressivo, ou seja, executar com mais frequencia... a idéia é que ele fique "sempre rodando rapidamente" na tabela... e não o contrário. > > <..corte..> > > Isso não é um problema, é apenas uma estatística sobre como seu > banco usa uma tabela. > > > Opa, blz então. Se fica somente na estatística, pode prejudicar a > utilização dos índices, certo? > Essa estatística que o Flávio mencionou não influencia diretamente nos planos de execução, se esse é seu receio. Que usa essa informação é o próprio "launcher" do autovacuum, mas também pode ser usada por sua ferramenta de monitoramento preferida para acompanhar os picos de mais "lixo" deixado pra trás em determinados objetos... uso muito essa informação para auxiliar no tuning do autovacuum. Att, [1] http://swebber.me/blog/2016/11/14/autovacuum-nao-e-o-inimigo/ -- 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
Re: [pgbr-geral] Seguencia de logs no audit trigger
On 22-11-2016 14:28, Alessandro Lima wrote:
> Boa tarde,
>
> Costumo pesquisar em meus logs do Audit Trigger ordenando por
> action_tstamp_stm para ver a sequencia de alterações em um registro.
> Mas percebi que em alguns casos os dados alterados estavam fora da ordem
> cronológica, constatei então que a ordem sequencial da chave primária
> event_id e da transaction_id não estão coerentes com a ordem crescente
> das datas, por exemplo:
> event_idtransaction_idaction_tstamp_txaction_tstamp_stmaction_tstamp_clk
> 9398667373628162016-11-17 09:17:59.453002-022016-11-17
> 09:17:59.460058-022016-11-17 09:17:59.460938-02
> 9398684673628482016-11-17 09:11:58.574255-022016-11-17
> 09:11:58.57457-022016-11-17 09:11:58.575121-02
> 9398685873628662016-11-17 09:12:21.143129-022016-11-17
> 09:12:21.143443-022016-11-17 09:12:21.166096-02
> 9398693573629852016-11-17 09:13:12.403124-022016-11-17
> 09:13:12.411809-022016-11-17 09:13:12.412167-02
>
> Exemplo da function que captura os logs:
> audit_row = ROW(
> nextval('audit.logged_actions_event_id_seq'),-- event_id
> current_timestamp,-- action_tstamp_tx
> statement_timestamp(),-- action_tstamp_stm
> clock_timestamp(),-- action_tstamp_clk
> txid_current(), -- transaction ID
>
> Alguém sabe me explicar o que está acontecento?
>
Jovem, execute o exemplo abaixo e vc entenderá a diferença:
BEGIN;
SELECT current_timestamp, clock_timestamp();
SELECT pg_sleep(60);
SELECT current_timestamp, clock_timestamp();
SELECT pg_sleep(60);
SELECT current_timestamp, clock_timestamp();
ROLLBACK;
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
Re: [pgbr-geral] PG Restore demorando muito
On 19-11-2016 14:05, Matheus de Oliveira wrote: > > <..corte..> > > [1] > https://www.postgresql.org/docs/current/static/populate.html#POPULATE-PG-DUMP > Interessante que na documentação ainda recomendam apenas um ANALYZE após o restore, sendo que somente ele não cria os FSM então não seremos beneficiados de imediado pelo IndexOnlyScan. 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
Re: [pgbr-geral] Replicação 9.2
On 16-11-2016 08:10, Mauricio SYSMO wrote: > Estou trabalhando com o postgreSQL 9.2.3 com replicação,, ao fazer r o > slave se recuperar por aquivos de Wall o slave vem perdendo a > sincronização e parando post, retornando o seguinte log : > > > Vc esta usando uma versão cheia de bugs, inclusive relacionados a replicação. Por favor atualize para 9.2.19, refaça seu slave (base backup) e acompanhe. 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
Re: [pgbr-geral] json para coluna
On 03-11-2016 23:57, Douglas Fabiano Specht wrote:
> Pessoal,
> como pego um objeto do tipo json e transformo ele em uma coluna?
> exemplo tenho um retorno de uma função ('[{"versaoatual":1}]' e gostaria
> de transformar ela em resultado normal de select coluna|valor
> exemplo:
> versaoatual
> 1
> isso e possivel?
>
Isso que vc precisa?
fabrizio=# SELECT json_extract_path_text('{"versaoatual":1}'::json,
'versaoatual');
json_extract_path_text
------------
1
(1 row)
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
Re: [pgbr-geral] Mensagem ao aplicar patch
On 03-11-2016 11:10, Neto pr wrote: > Olá, bom dia > Se alguém puder me indicar o que significa essa mensagem que foi > emitida ao aplicar um Patch nos fontes da versão 9.0.1. Eu verifiquei > os arquivos que o Patch altera do código fonte e a principio foram > alterados corretamente. > > Mensagem:" (Stripping trailing CRs from patch; use --binary to disable.) " > > -- Aplicação do comando e mensagem de alerta > projeto@neto-pc:~/Downloads/postgresql-9.0.1$ patch -p1 < > /home/projeto/Downloads/patchssdpg/0001-Split-up-page-cost-options-into-read-and-write.patch > (Stripping trailing CRs from patch; use --binary to disable.) > patching file doc/src/sgml/config.sgml > (Stripping trailing CRs from patch; use --binary to disable.) > patching file doc/src/sgml/indexam.sgml > (Stripping trailing CRs from patch; use --binary to disable.) > . > . > . > - > Tentou fazer como o git indicou ali pra vc: "use --binary do disable"??? Como vc fez download do patch??? Já tive problemas similares pelo simples fato de fazer download via gmail do patch em anexo. Tenta fazer download dele direto dos arquivos. 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
Re: [pgbr-geral] plpython
On 28-10-2016 11:52, Douglas Fabiano Specht wrote: > > bom dia pessoa > alguem sabe se nao existem mais os repositorios do plpython conforme o > link abaixo? > > https://wiki.postgresql.org/wiki/WIP:plpython3 > O que vc precisa exatamente? O plpython foi incorporado no "core" já há algum tempo (não lembro exatamente quanto) em src/pl/plpython [1]. Att, [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=tree;f=src/pl/plpython;h=2b0a2207580e0c01d2dc995348b0f8529f5e1d45;hb=HEAD -- 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
Re: [pgbr-geral] record to string
On 27-10-2016 13:33, Douglas Fabiano Specht wrote: > Boa tarde pessoal > preciso de uma ajuda. > tenho uma function onde tem um record de usuario, > preciso dar um update utilizando o campo record.id <http://record.id>, > mas teria que extrair todos os Id deste Record e coloca-lo num in...exemplo > > update usuario set salario=newsalario where id in(record.id > <http://record.id>) > > alguma solução? > Talvez usar Arrays ?? Poderíamos lhe ajudar melhor se o exemplo fosse mais completo. 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
Re: [pgbr-geral] Tamanho real da base em disco
On 26-10-2016 10:17, Sebastian Webber wrote: > Curioso do teu problema, eu fiz um teste aqui, veja: > > sebastian=# create table foo (id serial primary key, nome text); > CREATE TABLE > sebastian=# insert into foo (nome) select 'Nome ' || > generate_series(1,100); > INSERT 0 100 > sebastian=# \dt+ > List of relations > Schema | Name | Type | Owner | Size | Description > +--+---+---+---+- > public | foo | table | sebastian | 42 MB | > (1 row) > > > > Até aí, tudo bem, mas quando computo o tamanho do banco, acontece algo > diferente: > > sebastian=# select > pg_size_pretty(pg_database_size(current_database())); > pg_size_pretty > > 70 MB > (1 row) > Isso é normal, porque o metacomando \dt+ do psql [1] retorna o tamanho da tabela (incluindo FSM, VM e TOAST apartir da 9.0), ou seja, não considera índices. Att, [1] http://doxygen.postgresql.org/describe_8c.html#a773ee037ae1c052551ec298504d4a970 -- 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
Re: [pgbr-geral] pg_rman + AWS S3
On 21-10-2016 11:11, Flavio Henrique Araque Gurgel wrote: > > > Em sex, 21 de out de 2016 às 14:25, Cleiton Luiz Domazak > <cleitondoma...@gmail.com <mailto:cleitondoma...@gmail.com>> escreveu: > > 2016-10-20 16:21 GMT-02:00 Fabrízio de Royes Mello > <fabri...@timbira.com.br <mailto:fabri...@timbira.com.br>>: > > On 19-10-2016 16:44, Cleiton Luiz Domazak wrote: > > Boa tarde pessoal. > > > > Estou montando um projeto de PITR e estou utilizando o pg_rman. > Como são > > vários servers e não queremos manter um servidor só para rodar o > Barman, > > parti para WAL-e e pg_rman, e nos meus testes, para o nosso caso o > > pg_rman se mostrou ser a melhor opção, porém com a limitação de > não ter > > suporte nativo para envio ao S3 da Amazon. > > > > Alguém utiliza o pg_rman ou até mesmo o Barman enviando para S3? > Como > > que está configurado o upload e download dos backups e wals? > > > > O que estamos pensando em utilizar é algo como s3fs e mapear um > bucket, > > assim enviando direto para o S3, mas me preocupa a questão de > latência, > > quedas do s3fs, que já tive casos, e acabar perdendo o envio de > algum > > archive. Não seria o caso então de usar um disco de "stage", onde de > > tempos em tempos roda um rsync com o s3fs? Queria saber das pessoas > que > > já tiveram alguma experiência com um cenário parecido. > > > > Não tenho 100% de certeza mas acho que o wal-e [1] trata disso > pra vc. > > > Nos servidores na Amazon, tenho usado só o wal-e, com retenção > configurada direto no bucket S3. > Mesmo com os servidores fazendo muita escrita, o que gera muito wal, o > wal-e tem dado conta sem acumular demais os arquivos. Se isso acontecer, > você pode também otimizar o bucket para upload, em alguns casos chega a > dobrar a velocidade. > Bom saber disso... eu realmente não usei ele ainda em produção... > De qualquer forma, como vc mesmo mencionou, é recomendado vc ter um > "staging" local para archive e depois subir pro s3 ou para outro > storage > externo. > > > Eu não vejo qual a vantagem de fazer isso. O PostgreSQL lida muito bem > com os archives falhados, tudo o que é necessário é ter um espaço > suficiente para esses casos. Ter uma área de staging nada mais é do que > ter... espaço em disco extra. E um controle extra do envio, o que o > PostgreSQL já faz bem. > Talvez o Fabrízio tenha outra coisa em mente que não pesquei. > Realmente o PostgreSQL lida muito bem com essa questão de falha de arquivamento... pode ser preciosismo da minha parte mas tenho muito receio de colocar, por exemplo o s3cmd, direto no "archive_command" e por algum motivo ele retornar pro PostgreSQL Ok mas isso não ser verdade ... ou mesmo por algum motivo um segmento ficar corrompido por lá. Na verdade meu conhecimento de AWS é bem restrito então posso estar com receio de algo que nem é tão comum assim. > Tenho utilizado o pgBackRest [2] e pra subir pro s3 usamos o > s3fs+rsync > (vc tb já mencionou). > > > O problema do s3fs é que ele é montado com fuse, em espaço de usuário, > aí você precisa monitorar mais uma coisa se o sistema de arquivos morrer. > > Quando se faz rsync para o S3 (seja rsync comum num s3fs ou seja usando > a funcionalidade sync do comando 'aws s3' do awstools, cada verificação > de metadados consome banda - e isso a Amazon cobra *sem dó*. > Bom, esse detalhe eu realmente desconhecia ... obrigado pela dica! > Fica minha recomendação - wal-e e ponto. Mas tem mais gente na lista com > outras ideias :) > Confio no seu julgamento, então partiu testar ele então... > Uma alternativa pra quem precisa compartilhar entre vários servidores > sem passar pelo S3 é usar o novo "nfs gerenciado" que a Amazon acabou de > lançar. Eles têm empurrado bastante esse cara pra certos casos de uso. > Interessante... também irei verificar... Valeu pelas dicas Flávio. 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
Re: [pgbr-geral] pg_rman + AWS S3
On 19-10-2016 16:44, Cleiton Luiz Domazak wrote: > Boa tarde pessoal. > > Estou montando um projeto de PITR e estou utilizando o pg_rman. Como são > vários servers e não queremos manter um servidor só para rodar o Barman, > parti para WAL-e e pg_rman, e nos meus testes, para o nosso caso o > pg_rman se mostrou ser a melhor opção, porém com a limitação de não ter > suporte nativo para envio ao S3 da Amazon. > > Alguém utiliza o pg_rman ou até mesmo o Barman enviando para S3? Como > que está configurado o upload e download dos backups e wals? > > O que estamos pensando em utilizar é algo como s3fs e mapear um bucket, > assim enviando direto para o S3, mas me preocupa a questão de latência, > quedas do s3fs, que já tive casos, e acabar perdendo o envio de algum > archive. Não seria o caso então de usar um disco de "stage", onde de > tempos em tempos roda um rsync com o s3fs? Queria saber das pessoas que > já tiveram alguma experiência com um cenário parecido. > Não tenho 100% de certeza mas acho que o wal-e [1] trata disso pra vc. De qualquer forma, como vc mesmo mencionou, é recomendado vc ter um "staging" local para archive e depois subir pro s3 ou para outro storage externo. Tenho utilizado o pgBackRest [2] e pra subir pro s3 usamos o s3fs+rsync (vc tb já mencionou). Acho que vc está com tudo na mão, a "faca", o "queijo"... então "corte" ;-) Att, [1] https://github.com/wal-e/wal-e [2] http://www.pgbackrest.org/ -- 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
Re: [pgbr-geral] PostgreSQL 9.6 lançado
On 29-09-2016 12:26, Euler Taveira wrote: > Olá, > > Hoje foi lançada a versão 9.6. Veja as novidades em [1]. Eu já havia > comentado sobre algumas funcionalidades em [2]. > Show de bola... Na 9.6 trabalhei em duas funcionalidades: 1) ALTER TABLE foo ADD COLUMN [IF NOT EXISTS] bar INTEGER; 2) redução de bloqueios em ALTER TABLE ao alterar parâmetros do autovacuum e fillfactor; É importante ressaltar que a funcionalidade 2 foi patrocinada por uma empresa brasileira, a Zenvia [1] onde tínhamos problemas em efetuar tuning do autovacuum em algumas tabelas em produção, pois a plataforma de SMS deles é 24x7, e para contornar isso tinhamos que alterar direto no catálogo (pg_class.reloptions) o que pode levar a problemas se não for alterado corretamente. E repito que fazer alterações direto no catálogo pode levar a desastres então só faça isso se tiver absoluta certeza. Assim mais empresas brasileiras, como a Zenvia, pudessem apoiar mais o desenvolvimento e evolução do PostgreSQL assim como várias outras empresas estrangeiras já fazem há muitos anos. Att, Ps: isso só é possível por conta de projetos de código aberto e/ou livre [1] http://www.zenvia.com.br -- 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
Re: [pgbr-geral] Muitas ocorrências no LOG : postgres temporary file: path ...
On 13-09-2016 13:54, Luiz Henrique wrote: > Pessoal, > > Estou vendo muitas mensagens (logo abaixo) no log PostgreSQL. Sei que é > utilização do disco ao invés da memória. É muito constante, praticamente > direto a cada minuto! > > Vocês poderiam me ajudar a diagnosticar ? > Como reduzir ? > O que fazer para melhorar ? > O que seria um número aceitável ? > > Segue abaixo alguns parametros no postgresql.conf. Obrigado pelas dicas! > > Dados do S.O. > > Linux CentOS > Postgresql 9.1 > > Dados da Lâmina : > > SUN MICROSYSTEMS SUN BLADE X6270 M2 SERVER > Intel(R) Xeon(R) CPU E5620 2.40GHz > RAM 70 GB > Filesystem Size Used Avail Use% Mounted on > /dev/sda2 9.8G 1.3G 8.1G 14% / > tmpfs36G 0 36G 0% /dev/shm > /dev/sda1 488M 67M 396M 15% /boot > /dev/sda5 256G 5.8G 237G 3% /var > /dev/sdd1 493G 312G 156G 67% /var/lib/pgsql > /dev/sde1 985G 650G 285G 70% /var/backups > > Postgresql.conf > > shared_buffers = 32GB > temp_buffers = 48MB > work_mem = 16MB > maintenance_work_mem = 512MB > effective_cache_size = 45GB > > Trecho do log : > > 2016-09-13 13:23:02 BRT [18063]: [33-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp18063.15", size 10019576 > 2016-09-13 13:23:03 BRT [18063]: [35-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp18063.16", size 10443496 > 2016-09-13 13:23:04 BRT [18063]: [37-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp18063.17", size 10019576 > 2016-09-13 13:23:05 BRT [18063]: [39-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp18063.18", size 10443496 > 2016-09-13 13:23:06 BRT [18063]: [41-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp18063.19", size 10019576 > 2016-09-13 13:23:07 BRT [18063]: [43-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp18063.20", size 10443496 > 2016-09-13 13:23:07 BRT [18063]: [45-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp18063.21", size 10019576 > 2016-09-13 13:23:08 BRT [18063]: [47-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp18063.22", size 10443496 > 2016-09-13 13:23:09 BRT [18063]: [49-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp18063.23", size 10019576 > 2016-09-13 13:23:32 BRT [18063]: [51-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp18063.24", size 10443496 > 2016-09-13 13:23:32 BRT [18063]: [53-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp18063.25", size 10019576 > 2016-09-13 13:25:19 BRT [17440]: [28-1] user=xyz,db=xyz,client=a.b.c.d > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp17440.10", size 53116928 > Considere aumentar o seu "work_mem" e verifique novamente. Não precisa de "restart", basta um "reload" para efetivar a alteração. 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
Re: [pgbr-geral] Diversão com restrições
On 08-09-2016 16:55, Guimarães Faria Corcete DUTRA, Leandro wrote: > http://www.anserinae.net/fun-with-sql-constraints.html > > Ponto para quem explicar sucintamente em bom português. > Qual a dúvida meu guri? Um índice parcial é criado para agir em uma porção da tabela de acordo com o predicado definido (aka WHERE), então você pode criar um índice regular ou um "unique" que irá respeitar as tuplas envolvidas na porção definida pelo mesmo. -- 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
Re: [pgbr-geral] Lentidão no Postgres 9.5
On 08-09-2016 09:43, Irineu Raymundo wrote:
> Bom dia pessoal,
>
> Estou com um problema de lentidão numa rotina, se alguém puder me dar
> uma luz do que eu poderia investigar fico imensamente agradecido.
>
> O banco é : "PostgreSQL 9.5.4 on x86_64-pc-linux-gnu, compiled by gcc
> (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609, 64-bit"
>
> A trava aparentemente de forma aleatória, executa 2 dias normalmente e
> parece que do nada trava na última função e fica mais de 4 horas sendo
> obrigado a derrubar.
>
> Conferi quando trava e não tem nenhuma outra instrução que poderia faz
> um lock nas tabelas.
>
> Basicamente ela cria tabelas temporárias, faz os cálculos necessários e
> escreve numa tabela não logada(UNLOGGED) para poder imprimir o relatório
> via ODBC.
> Essa tabela fica com mais ou menos 2 milhões de registros, e tem uns 11
> índices.
>
> Segue abaixo a rotina:
>
> TRUNCATE senda.ind_03_03_04_01_lev CASCADE;
> TRUNCATE senda.ind_03_03_04_01_01_lev CASCADE;
> TRUNCATE senda.ind_03_03_04_01_01_a1_lev;
> REINDEX TABLE senda.ind_03_03_04_01_lev;
Porque o REINDEX em uma tabela que vc recém efetuou um TRUNCATE? O
TRUNCATE recria todos datafiles envolvidos (heap e btree).
> VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_lev;
> VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_a1_lev;
> VACUUM FULL ANALYZE senda.ind_03_03_04_01_lev;
> VACUUM FULL ANALYZE senda.ind_03_03_03_02_oc;
Aqui vc efetua um VACUUM FULL novamente e talvez sem necessidade,
principalmente pelo fato da "senda.ind_03_03_04_01_lev" ter sido
truncada anteriormente. Será que as demais tabelas não são truncadas
junto com as anteriores devido ao "CASCADE"???
> SET temp_buffers=3;
Setando dessa forma vc está informando ao PostgreSQL para usar ~234,38MB
= (3*8kB)/1024.
> SELECT senda.ins_mat_lev_cria_indices();
> SELECT senda.ins_mat_lev_1('98');
> SELECT senda.ins_mat_lev_2('98');
> SELECT senda.ins_mat_lev_3('98');
> SELECT senda.ins_mat_lev_4('98');
> SELECT senda.mat_marca_cliente_lev('98','LEVMAT',NULL,1256);
>
Dificil te ajudar sem saber exatamente o que essas PLs fazem.
> Até esse ponto vai tranquilo, coisa de 5 minutos, a próxima função
> descarrega os registros( 2 milhões) das temporáriad para as tabelas
> UNLOGGED e aí que trava de vez em quando.
>
Precisamos de mais detalhes para poder ajudar!
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
Re: [pgbr-geral] Parâmetros kernel
On 30-08-2016 17:13, Franklin Anderson de Oliveira Souza wrote: > Olá diógenes ! > > Por favor, evitem o top-posting... > Não sei bem exatamente de qual versão do postgresql mas essas > configurações de kernel, pelo que me disseram não precisa mais na 9.3. > Alguém confirma ?! > Os parâmetros relativos a memória compartilhada não precisam, mas outros parâmetros irão depender muito do seu ambiente. 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
Re: [pgbr-geral] Dúvida sobre imagem(Docker) PostgreSQL
On 29-08-2016 20:30, Fabrízio de Royes Mello wrote: > On 29-08-2016 20:06, Rafael Nery wrote: >> Boa noite pessoas, >> >> Alguém saberia me dar uma dica de Imagem do Postgres no dockerhub que >> rode em cima do AlpineLinux? >> > > Pesquisando no DockerHub apareceram algumas opções conforme [1]. > > Att, > > [1] > https://hub.docker.com/search/?isAutomated=0=0=1=0=postgres+alpine=0 > Complementando, um daqueles listados tem várias imagens publicadas baseado em alpine [1] Att, [1] https://github.com/kost/docker-alpine -- 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
Re: [pgbr-geral] Dúvida sobre imagem(Docker) PostgreSQL
On 29-08-2016 20:06, Rafael Nery wrote: > Boa noite pessoas, > > Alguém saberia me dar uma dica de Imagem do Postgres no dockerhub que > rode em cima do AlpineLinux? > Pesquisando no DockerHub apareceram algumas opções conforme [1]. Att, [1] https://hub.docker.com/search/?isAutomated=0=0=1=0=postgres+alpine=0 -- 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
Re: [pgbr-geral] Crash durante vacuum full
On 29-08-2016 07:58, Luiz Carlos L. Nogueira Jr. wrote:
> Pessoal,
>
> Estávamos fazendo um vacuum full quando a VM "crashou".
> Depois de conseguirmos reiniciá-la, fizemos novamente o vacuum full e
> ele terminou normalmente.
> Só que quando vi, o tamanho do banco ficou uns 130GB maior, que é
> justamente o tamanho da tabela que estava tendo o vacuum quando "crashou".
> Olhando os tamanhos das maiores tabelas do banco, elas estão normais.
> Como fazer pra encontrar esse "espaço perdido"?
>
Já vi isso acontecer *eventualmente* pois o que ocorre é que o VACUUM
FULL reescreve em disco todos os datafiles e só faz o swap e remove os
antigos quando a transação for finalizada (aka commit). Quando acontece
um rollback em situações normais os novos datafiles que estavam sendo
gerados durante o processo sao removidos pelo PostgreSQL.
Então é bem provável que tenham ficado datafiles *perdidos* dentro do
seu $PGDATA/base/OID_DA_SUA_BASE.
Pelo meu histórico pessoal uma vez eu usei uma query pra identificar
esse fenômeno e determinar se essa teoria era correta. Tente usar a query:
SELECT file,
(file_stat).size,
pg_size_pretty((file_stat).size),
(file_stat).modification
FROM (SELECT file,
pg_stat_file('base/'||(SELECT oid FROM pg_database WHERE
datname = current_database())||'/'||file) as file_stat
FROM pg_ls_dir('base/'||(SELECT oid FROM pg_database WHERE
datname = current_database())) AS file
WHERE file ~ '[0-9]$'
AND file !~ '^t'
AND NOT EXISTS (SELECT 1
FROM pg_class
WHERE relfilenode::integer =
split_part(file,'.',1)::integer)) AS file
WHERE (file_stat).modification::date < current_date
ORDER BY 1;
Até onde me lembro ela não é 100% OK (creio que tenha que desconsiderar
tabelas temporarias)... mas pode ser um inicio.
De qualquer forma quando detectei de fato esse problema eu resolvi
fazendo dump/restore em um novo cluster com initdb.
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
Re: [pgbr-geral] wal files - aumentar número de arquivos
On 04-08-2016 18:07, Patrick B wrote: > > > Procure por "archive_mode" e "archive_command" na documentação. > > > Eu já utilizo esses comandos. Mas não consigo arquivar os wal_files por > 30 dias através destes comandos. > Mas a decisão por "manter" esses caras arquivados não é responsabilidade do PostgreSQL. Vc precisa implementar uma forma de expurgar eles após 30 dias, nada que um "find" não te ajude. 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
Re: [pgbr-geral] wal files - aumentar número de arquivos
On 04-08-2016 17:12, Patrick B wrote: > > Sugiro arquivar o WAL e guardá-los por 30 dias. > > > Como? é isso que quero saber > Procure por "archive_mode" e "archive_command" na documentação. 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
Re: [pgbr-geral] Uso de custom_variable_classes
On 03-08-2016 18:13, Heloisa Fernanda wrote: > Olá pessoal! > > Estou procurando uma alternativa para "setar" o usuário da aplicação > durante uma transação e pegar isso em uma trigger. > Vi algumas pessoas usando o custom_variable_classes. Alguém da lista > esta usando isso? Tem algum problema com performance? Ou algum risco de > usar esse recurso para esse fim? > Heloisa, Existem diversas formas de vc manter "variáveis de sessão" no seu banco de dados, e IMHO usar "custom_variable_classes" (aka dynamic gucs) são a melhor alternativa pois quase não existe overhead. Inclusive há alguns anos escrevi uma extensão [1] pra manipular variáveis de sessão. Att, Ps: dependendo da versão que vc está usando do PostgreSQL não é necessário registrar o "custom_variable_classes" no postgresql.conf [1] http://pgxn.org/dist/session_variables/0.0.4/ -- 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
[pgbr-geral] Transmissão AO-VIVO do PGDay POA durante o FISL17
Pessoal, O PGDay POA está sendo transmitido ao vivo do FISL17. Acesse o link [1] e clique na SALA 41E. Att, [1] http://softwarelivre.org/fisl17/programacao/fisl17-ao-vivo -- 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
Re: [pgbr-geral] Nova camiseta "PostgreSQL Rock solid database"
On 05-07-2016 14:50, Fábio Telles Rodriguez wrote: > Fiz uma pequena publicação para divulgar a > camiseta: http://savepoint.blog.br/download/elefante_postgreSQL.pdf > Favor não fazer top-posting. O link correto não seria: http://savepoint.blog.br/camiseta-comemorativa-dos-20-anos-do-postgresql/ 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
Re: [pgbr-geral] ALTER SYSTEM
On 04-07-2016 09:22, Douglas Fabiano Specht wrote: > bom dia pessoal, > foi adicionado algumas configurações por alter system, e neste caso o > postgres cria um arquivo chamado postgresql.auto.conf, que utiliza as > configurações deste arquivo ao inves do padrão. > caso eu faça um ALTER SYSTEM RESET ALL ele volta a ler o que esta dentro > do postgresql.conf? > Sim. -- 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
Re: [pgbr-geral] connections on unix domain socket ubuntu 16.04 /var/run/postgresql/.s.pgsql.5432
On 27-06-2016 20:25, Gian wrote: > Pessoal, estou quebrando a cabeça com este problema, alguem poderia me > dar uma luz, ja pesquisei muito e não consigo resolver. > Instalei o postgres 9.5 no ubuntu server 16.04 e não consigo acessar. > Vc poderia ser um pouco mais claro e explicar exatamente o que vc fez (copiando e colando comandos) e que erros apareceram pra vc? Até onde me recordo nessas distro por padrão apenas o usuário "postgres" via ident tem acesso liberado no cluster, ou seja, vc precisa estar logado com usuário "postgres" do Linux para tentar acessar. Mas também o erro pode ser por o serviço não estar rodando, o que aparece qdo vc digita "pg_lsclusters" ? 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
Re: [pgbr-geral] Espaço Comunidade no FISL17
On 22-06-2016 11:37, Fernando Ike wrote: > On Sat, 28 May 2016 09:12:43 -0300 > Fabrízio de Royes Mello <fabri...@timbira.com.br> wrote: > >> Bom dia pessoal, >> >> Está aberta chamada para espaços da comunidade dentro do FISL17 [1]. >> Ter uma banca na Área de Comunidades, no espaço de exposições do >> FISL17 pode ser uma ótima forma divulgar a comunidade, projetos e o >> próprio mini-evento dentro do FISL. >> >> O que vcs acham?? >> > Sensacional! Pena que não poderei ir este ano. :( > Pena... mas nem inscrevi lá o espaço comunidade porque ninguém se manifestou para ajudar e já tenho o PGDay pra cuidar. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Não é possivel executar fsync ... bad file descriptor
On 13-06-2016 15:14, Bruno Felipe wrote: > Entendi. está na 9.2.2, da para atualizar binários no windows? > Claro, vc deve fazer isso. -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Não é possivel executar fsync ... bad file descriptor
On 13-06-2016 10:33, Bruno Felipe wrote: > aconteceu na seguinte forma, > selecionei o database > cliquei em manitence > escolhi o vaccum > cliquei em ok > passou alguns segundos e apareceu o erro > Por favor Bruno não faça top-posting. Vc descobriu qual é o objeto problemático como o Flávio comentou?? Verifique com: SELECT * FROM pg_class WHERE relfilenode = 1329923; Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas com ‘alternativas’ ao modelo relacional
On 09-06-2016 12:51, Guimarães Faria Corcete DUTRA, Leandro wrote: > 2016-06-09 12:47 GMT-03:00 Fabrízio de Royes Mello <fabri...@timbira.com.br>: >> On 08-06-2016 14:55, Guimarães Faria Corcete DUTRA, Leandro wrote: >>> https://engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827#.phpzbdxtf >> >> IMHO o problema descrito tem mais a ver com a forma como a ferramenta >> implementa controle de concorrência do que o modelo de dados em si. > > É verdade, a rigor. Mas veja que ‘não há almoços grátis’; quando Claro que não há almoço grátis... > alguém promete algo melhor que o relacional, geralmente o que fez foi > gambiarra mesmo. > Não concordo com essa afirmação equivocada que muitos fazem por ai, porém o que tenho visto é que o BASE não foi criado para tentar ser melhor ou um substituto do ACID. Foi criado para atender cenários em que o ACID não se sai tão bem assim e que não precisamos de sua rigidez. Então é mais uma ferramenta no arsenal do engenheiro para resolução de problemas. Tecnologias são ferramentas e surgem para resolver um conjunto de problemas em um determinado cenário (ou vários, dependendo). A questão é que não existe bala de prata e com apenas uma ferramenta resolvemos todos nossos problemas. Tenho sempre em mente uma frase que escutei uma certa vez em um evento "nem todo problema é prego pra pegar o martelo e sair resolvendo". Lembremos sempre que sistemas distribuídos são complexos por natureza, e quando precisamos manter estado (como banco de dados) a complexidade é ainda maior. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas com ‘alternativas’ ao modelo relacional
On 08-06-2016 14:55, Guimarães Faria Corcete DUTRA, Leandro wrote: > https://engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827#.phpzbdxtf > > E isso é o mais famoso hoje. Infelzmente, já tão popular que, em vez > de voltar para o mundo relacional, provavelmente vão conviver com o > problema, talvez gambiarrá-lo, e mesmo que se resolva será só esperar > o próximo… quem não aprende com a história (de que necessidades e > problemas o modelo relacional começou a resolver), está condenado a > repeti-la — como farsa. > IMHO o problema descrito tem mais a ver com a forma como a ferramenta implementa controle de concorrência do que o modelo de dados em si. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ 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 com aggregate no Postgres 9.5
On 07-06-2016 17:04, Irineu Raymundo wrote: > Pessoal boa tarde, > > Estou faznedo alguns teste visando a migração do PostGres 9.0 para 9.5 . > > No 9.0 havia 1 aggregate: array_agg(anyelement), mas no 9.5 tem 2: > array_agg(anyarray) e array_agg(anynonarray). > > Ao executar um SELECT pela aplicação está apresentando a seguinte mensagem: > > "SQL Error: ERROR: function array_agg(character varying) is not unique > at character 1657 > HINT: Could not choose a best candidate function. You might need to add > explicit type casts." > > Alguém já passou por isso? Existe alguma forma de contornar sem ter que > reescrever o SQL? > Irineu, Vc tem certeza que não tem nenhum "custom aggregate" na sua base de dados?? No psql digite "\da array_agg" e cole o que mostra. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] CPU em 100%
On 04-06-2016 12:13, Tales Costa wrote: > Boa tarde, > > De uns dias para cá estou enfrentando alguns problemas com um servidor > Postgresql + Zabbix. O pg está consumindo em muitos momentos 100% da CPU > do server, ocasionando o aumento da temperatura da mesma. > > Como não tenho experiência alguma com postgresql, estou na dúvida se o > problema é de hardware ou algo relacionado ao pg pois funciona > perfeitamente antes de migrar o servidor fisicamente de lugar e > atualizar a versão do PG e alguns outros pacotes. > > Observei que o aumento de CPU sempre ocorre quando é executado alguns > "select". Segue imagem do htop. > > Segue algumas informações: > > $ /usr/lib/postgresql/9.1/bin/postgres -V > postgres (PostgreSQL) 9.1.22 > > $ uname -a > Linux zabbix 3.2.0-4-amd64 #1 SMP Debian 3.2.78-1 x86_64 GNU/Linux > # Testei também com a 4.6.1. > > $ ps aux | grep zabbixdb | wc -l > 63 > > $ cat /etc/postgresql/9.1/main/postgresql.conf | egrep -v ^# > > data_directory = '/var/lib/postgresql/9.1/main'# use data in another > directory > hba_file = '/etc/postgresql/9.1/main/pg_hba.conf'# host-based > authentication file > ident_file = '/etc/postgresql/9.1/main/pg_ident.conf'# ident > configuration file > external_pid_file = '/var/run/postgresql/9.1-main.pid'# write an extra > PID file > listen_addresses = '*'# what IP address(es) to listen on; > port = 5432# (change requires restart) > max_connections = 120# (change requires restart) > unix_socket_directory = '/var/run/postgresql'# (change requires restart) > ssl = true# (change requires restart) > password_encryption = on > log_line_prefix = '%t '# special values: > autovacuum = on# Enable autovacuum subprocess? 'on' > log_autovacuum_min_duration = -1# -1 disables, 0 logs all actions and > autovacuum_max_workers = 1# max number of autovacuum subprocesses > autovacuum_naptime = 1min# time between autovacuum runs > datestyle = 'iso, dmy' > lc_messages = 'pt_BR.UTF-8'# locale for system error message > lc_monetary = 'pt_BR.UTF-8'# locale for monetary formatting > lc_numeric = 'pt_BR.UTF-8'# locale for number formatting > lc_time = 'pt_BR.UTF-8'# locale for time formatting > default_text_search_config = 'pg_catalog.portuguese' > > #Restante está tudo default > > [...corte...] > Tales, A configuração padrão do PostgreSQL é bem conservadora. Sugiro dar uma olhada no pgconfig [1] para tentar um tuning inicial mais adequado do que a configuração padrão. Outro ponto que arrisco a pensar (por conta de coleta de monitoramento) é que seu banco pode sofrer de estatísticas desatualizadas muito cedo fazendo com que o planejador tome caminhos ruins para execução das queries e por consequencia usando mais recursos do seu servidor. Tente rodar um "VACUUM ANALYZE" no seu database e observe se ocorre uma melhora e nos conte. Att, [1] http://www.pgconfig.org/ -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função com retorno de vários dados
On 03-06-2016 12:53, Ricardo wrote: > > > *From:* Sebastian Webber <mailto:sebast...@swebber.me> > *Sent:* Friday, June 03, 2016 12:14 PM > *To:* Comunidade PostgreSQL Brasileira > <mailto:pgbr-geral@listas.postgresql.org.br> > *Subject:* Re: [pgbr-geral]Função com retorno de vários dados > > > > Em 3 de junho de 2016 11:49, Ricardo <rica...@longomaquinas.com > <mailto:rica...@longomaquinas.com>> escreveu: > > Bom dia pessoal. > > Sempre trabalhei com a variável tipo record para retorno uma > tabela em uma função usando esse procedimento. > > FOR VARIABLE IN SELECT * FROM TABELA > LOOP > > > > Porém agora preciso criar uma função onde vai ter o número > inicio e o número fim que vai me determinar o número de registros no > retorno, ou seja, não vou mais utilizar um select. Alguém pode me > dar uma orientação de como fazer isso ? > > > Sugiro que vc verifique as clausulas LIMIT[1] e OFFSET. > > [1] https://www.postgresql.org/docs/current/static/queries-limit.html > > > -- > Sebastian Webber > http://swebber.me > > Já resolvi pessoal, > ficou assim > > CREATE OR REPLACE FUNCTION public."_Tabela_Consulta" ( > "Par_Inicio" integer, > "Par_Fim" integer, > out "Par_Consumo" numeric, > out "Par_Valor" numeric > ) > RETURNS SETOF record AS > $body$ > DECLARE > Contador_Inicio INTEGER; > > Faixa_Inicio INTEGER; > Faixa_Fim INTEGER; > Faixa_Valor NUMERIC( 10, 2 ); > Faixa_Fixa BOOLEAN; > > Faixa_Calculo INTEGER; > Consumo_Calculo NUMERIC( 10,2 ); > Valor_Calculo NUMERIC( 10, 2 ); > > BEGIN > > Contador_Inicio := "Par_Inicio"; > > WHILE Contador_Inicio < "Par_Fim" > LOOP > > > > "Par_Consumo" := Contador_Inicio; > "Par_Valor" := Valor_Calculo; > > Contador_Inicio := Contador_Inicio + 1; > > RETURN NEXT; > > END LOOP; > > RETURN; > > END; > $body$ > LANGUAGE 'plpgsql' > VOLATILE > CALLED ON NULL INPUT > SECURITY INVOKER > COST 100 ROWS 1000; > Porque fazer tudo isso se no SQL existe o LIMIT conforme o Sebastian sugeriu??? Além de simplificar vc terá inclusive ganhos de performance. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] [Off-Topic] Inscrições abertas para DevOpsDay/POA
Pessoal, Inscrições do primeiro lote do DevOps Day Porto Alegre estão abertas! Não perca o tempo aproveitar um bom desconto na inscrição! É até dia 13 de junho! http://www.devopsdayspoa2016.eventize.com.br/index.php Para quem quiser ajudar na divulgação, temos o links abaixo para compartilhamento: Facebook: https://www.facebook.com/devopsdaypoa/photos/a.514181408765669.1073741827.514178092099334/520385841478559/?type=3 Twitter: https://twitter.com/poadevopsday/status/738789748593025024 Linkedin: http://www.linkedin.com/hp/update/6144556337083793408 Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consideração replicação
On 31-05-2016 10:10, Luiz Carlos L. Nogueira Jr. wrote: > Flávio, > > Outra dúvida simples. A replicação deixa os bancos "iguais" tanto > fisicamente quanto logicamente? > > Por ex. A fragmentação de um lado não poderia ser diferente do outro? > O slave da replicação nativa é um "clone físico" do master porque a replicação é feita a nivel de páginas e não no nivel lógico (sql). Portanto são exatamente iguais (nivel fisico e lógico) e a fragmentação tb será a mesma visto que é uma réplica física. Nesse tipo de replicação se vc tem objetos inchados e efetuar uma manutenção no master para resolver isso, esta manutenção será "replicada" para o slave. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Espaço Comunidade no FISL17
Bom dia pessoal, Está aberta chamada para espaços da comunidade dentro do FISL17 [1]. Ter uma banca na Área de Comunidades, no espaço de exposições do FISL17 pode ser uma ótima forma divulgar a comunidade, projetos e o próprio mini-evento dentro do FISL. O que vcs acham?? Att, [1] http://softwarelivre.org/fisl17/programacao/comunidades -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Habilitar a engine innoDB no mysql
On 23-05-2016 17:25, Leandro Guimarães Faria Corcete DUTRA wrote: > Le 23 mai 2016 17:23:55 GMT-03:00, Dark_Angel > <jonnathann.finiz...@dce.ufpb.br> a écrit : >> Olá pessoal, tudo bem? Sei que essa pergunta não é voltada aos usuários >> do >> PostgreSQL, mas se alguém puder me ajudar, eu agradeceria bastante! > > Recomendo perguntar numa lista de MySQL. > Ou então lá na DBA Brasil [1]. Tem várias pessoas que manjam bastante de MySQL. Att, [1] https://groups.google.com/group/dba-brasil -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: lo_import em banco de dados remoto
On 23-05-2016 12:34, Matheus Saraiva da Silva wrote: > Estou usando C#. > Para tecnologias micrsoft existe o ODBC, mas sempre ouvi mal dizeres sobre > ODBC. > Então encontrei o Npgsql (http://www.npgsql.org/about.html) opensource > desenvolvido em C#. Vou olha na documentação para tentar encontrar algo a > respeito. > Não faça top-posting por favor. Tem sim, olhe na doc do Npgsql [1] Att, [1] http://www.npgsql.org/doc/large-objects.html -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] lo_import em banco de dados remoto
On 22-05-2016 12:22, Matheus Saraiva wrote:
> Mandei uma pergunta similar a essa, mas como tinha poucas informações
> talvez isso implicou em se obter uma resposta. Dessa forma estou
> reformulando a pergunta com mais informação bem como com novas descobertas.
> Pela primeira vez estou precisando gravar arquivos no banco. No meu caso
> eu optei por usar coluna do tipo OID.
>
Na próxima vez para manter o contexto e organização da lista responda a
sua própria pergunta passando mais informações.
> Em uma base de dados localhost, o insert seria assim:
>
> |INSERT INTO fruit VALUES ('peach', lo_import('/usr/images/peach.jpg'));|
>
> Mas e se eu precisar inserir esse mesmo arquivo em um banco de dados remoto?
>
> Nesse exemplo de insert que fiz funciona se a base de dados estiver
> local, pois |lo_import| irá buscar o arquivo na máquina onde está
> instalado o servidor.
>
Exato.
> Mas eu preciso fazer um insert de uma máquina cliente, ou seja, o
> arquivo está na máquina cliente e o insert deve mandar esse arquivo da
> máquina cliente para o servidor.
>
Para isso vc deve utilizar via libpq através do driver/componente que a
implementa na sua linguagem de programação. Que linguagem vc está usando?
Att,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Particionamento
On 20-05-2016 16:26, Fabrízio de Royes Mello wrote: > On 20-05-2016 14:48, Felipe Santos wrote: >> >> Olá Danilo, >> >> Nenhum dos dois. >> >> Ele lê o índice do campo particionado nas tabelas filhas para saber se >> deve entrar nos mesmos ou não. >> >> A trigger e os checks são acionados apenas nos eventos DML. >> > > Danilo, > > Infelizmente vc está equivocado... > > [...] > Oops... quis fizer Felipe... Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Particionamento
gt;= '2016-05-20'::date) AND (partkey <= '2016-05-21'::date)) -> Seq Scan on foo_20160520 Filter: ((partkey >= '2016-05-20'::date) AND (partkey <= '2016-05-21'::date)) -> Seq Scan on foo_20160521 Filter: ((partkey >= '2016-05-20'::date) AND (partkey <= '2016-05-21'::date)) (7 rows) Note que após adicionar as CHECK CONSTAINTS o planejador começou a ter conhecimento de quais partições precisava efetuar a busca de acordo com o predicado. E também não existe nenhum índice associado a coluna "partkey" que foi utilizada como chave do particionamento. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consideração replicação
On 20-05-2016 13:08, Matheus Ricardo Espanhol wrote: > E apartir da 9.5 temos os Replication Slots e dai vc nem precisa se > preocupar com archiving. > > Att, > > [1] > > http://www.postgresql.org/docs/9.5/static/warm-standby.html#STREAMING-REPLICATION-SLOTS > > > Bem lembrado Fabrizio. Mas vale o alerta que esta alternativa pode > acumular xlogs no master indefinidamente em caso de indisponibilidade > do slave. > Certamente, por isso precisamos *sempre* monitorar nosso SGBD... e em caso de indisponibilidade muito grande do slave remove-se o Replication Slot e vida que segue. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consideração replicação
On 20-05-2016 11:59, Matheus Ricardo Espanhol wrote: > > > 2016-05-20 10:14 GMT-03:00 Luiz Carlos L. Nogueira Jr. > <lcnogueir...@gmail.com <mailto:lcnogueir...@gmail.com>>: > > > Matheus, > > A minha ideia é ter o master no modo archive, mas não sei das > vantagens/desvantagens desse modo no slave. > > > No slave não será necessário o modo archive. > Não precisa fazer nada no slave pois quando o PostgreSQL está em standby ele não arquiva o wal. O worker do arquivamento é iniciado depois somente se for promovido, entao tanto faz a configuração que tenha nos parametros archive_*. [...] > Se eu fizer em um ou em outro o archive_command do que não fizer > será um comando qualquer que retorne true ou posso deixar null? > > > Você pode manter o archive_mode habilitado e utilizar algo como 'exit 0' > no slave. Isso é apenas para evitar um futuro restart caso queira voltar > arquivar. Lembre-se que o arquivamento será feito pelo pg_receivexlog e > é obrigatório para gerar o backup base. > Como falei acima não precisa fazer nada em relação aos parametro "archive_*" no slave. [...] > *--Mas, onde enfileirará caso o master fique esperando o slave? Se > no archive, os dados poderão, dependendo do tempo, estar no wal, mas > se não tiver no archive mode, a replicação "morre" e terei de fazer > tudo do 0 de novo?* > > > Mesmo não estando no modo archive, a replicação streaming se sincroniza > através do WAL. Portanto, você pode manter alguns xlogs com o parâmetro > wal_keep_segments. Em um cenário onde você tem um backup PITR ativo > (archive) você ainda pode contar com os xlogs salvos no servidor de > backup para fazer o sincronismo quando o slave voltar. > > Após o sincronismo através do WAL, o slave irá se conectar no master > para iniciar a replicação. > E apartir da 9.5 temos os Replication Slots e dai vc nem precisa se preocupar com archiving. Att, [1] http://www.postgresql.org/docs/9.5/static/warm-standby.html#STREAMING-REPLICATION-SLOTS -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Failed to archive WAL segment - PostgreSQL 9.2
On 18-05-2016 00:32, Lucas Possamai wrote: > > [..corte..] > Acho que você está desinformado. Benchmarks comprovam que shared_buffers > alto (dezenas de GB) não escala em TPS. > > > posso estar... também fiz vários testes como mencionei.. também falei > com um monte de gente... e parecia a melhor solução.. > > mas na prática não funcionou foi pior > Desculpe mas ficou confuso pois pelo que entendi lendo emails anteriores o seu "pior" foi por conta da falha do arquivamento... posso também ter entendido errado. O que vc julga como "pior"?? Performance?? Vc tem dados para nos fornecer?? Além disso vc disse que ao alterar o shared_buffers o PostgreSQL não iniciou, vc poderia fornecer as entradas no log que indicam o problema? Como o Euler já mencionou um valor de shared_buffers impacta em um checkpoint mais demorado e durante o stop do serviço o PostgreSQL efetua um para ele poder "parar em um estado consistente" e não necessitar de um "recovery" no próximo "start". Se vc forçou o "stop" do serviço para ser mais rápido então no próximo "start" ele entrará em "recovery" e isso pode demorar algum tempo. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
