Re: [pgbr-geral] restore baseado em cópia do hd

[Sebastian Webber]

Em 18 de abril de 2018 15:30, Alessandro Lima <grandegoia...@gmail.com>
escreveu:

> Boa tarde,
>
> Preciso restaurar uma base de dados a partir de uma cópia dos arquivos do
> sistema operacional.
> Gostaria de confirmar se precisa ser o mesmo sistema operacional e mesma
> versão do postgresql?
> Basta ser Windows 64bits, ou tem que ser exatamente Windows 2012 R2 64bits
> como era o caso.
> Basta ser 9.4, posso pegar a última 9.4.17.
>

Nesse caso, vai funcionar.

O ideal é manter o mesmo FS, tipo (32/64 bits) plataforma (windows, linux,
etc) e  versão (no caso, 9.4.x é compativel).

Só precisa conferir as permissões.

PS: Não te esquece de se cadastrar na lista nova!!!
https://www.postgresql.org/list/pgsql-pt-geral

-- 
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>?  Dá uma olhada no que eu ando
aprontando: http://swebber.me
___
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: [archiver] entry ID 0 out of range -- perhaps a corrupt TOC

[Sebastian Webber]

Em 13 de abril de 2018 08:25, Alexsandro Haag <alexsandro.h...@gmail.com>
escreveu:

> Em 13/04/2018 01:56, Sebastian Webber escreveu:
>
> O que acontece quando tu roda o comando abaixo?
> pg_restore --list arquivo.dump
>
> Bom dia Sebastian,
>   rodei aqui e exibe também a mesma mensagem:
>
> pg_restore --list troll.cop
> pg_restore: [archiver] entry ID 0 out of range -- perhaps a corrupt TOC
>
>
O arquivo ta bem com cara de corrompido.  Qual é o tamanho dele? Como tu
faz pra gerar o mesmo?

-- 
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>?  Dá uma olhada no que eu ando
aprontando: http://swebber.me
___
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: [archiver] entry ID 0 out of range -- perhaps a corrupt TOC

[Sebastian Webber]

Em 12 de abril de 2018 21:59, Alexsandro Haag <alexsandro.h...@gmail.com>
escreveu:

> Olá pessoal,
>
>
Opa, boa noite!


>  já viram este erro ao tentar executar o restore de um dump via pg_restore?
>
> pg_restore: [archiver] entry ID 0 out of range -- perhaps a corrupt TOC
>


O que acontece quando tu roda o comando abaixo?
pg_restore --list arquivo.dump



-- 
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>?  Dá uma olhada no que eu ando
aprontando: http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Base de dados de CEP do Brasil.

[Sebastian Webber]

Em 9 de março de 2018 09:14, Rafael Bragatto Gratz <
raf...@projetasistemas.com.br> escreveu:

> Genial Wilian, valeu pela dica.
>

WOW! 2 anos depois e veio a resposta. hehehehe


[]'s




-- 
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>?  Dá uma olhada no que eu ando
aprontando: http://swebber.me
___
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

[Sebastian Webber]

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

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

Re: [pgbr-geral] Slides - PGBR 2017

[Sebastian Webber]

Em sex, 22 de set de 2017 às 11:12, Fabiano Machado Dias <
fabi...@wolaksistemas.com.br> escreveu:

> Queria muito ver a palestra do Emerson Engroff, PG em Memória,
> infelizmente não consegui ir pela manhã no evento.
>
>
Ele acabou não vindo e usamos a sala pra extender outra palestra.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Slides - PGBR 2017

[Sebastian Webber]

Em sex, 22 de set de 2017 às 10:51, Fabiano Machado Dias <
fabi...@wolaksistemas.com.br> escreveu:

> Bom dia,
>
> Alguém sabe quando serão disponibilizados os slides das palestras do PGBR?
>

E ai Fabiano, tudo bem?

Alguns deles já estão no site.

Estou atualizando os mesmos conforme o pessoal vai me mandando.

--
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Cliente - Ransonware

[Sebastian Webber]

Em seg, 11 de set de 2017 às 12:23, José Mello Júnior <
jose.mello.jun...@gmail.com> escreveu:

> Alo pessoal,
>
> Cliente teve problemas com ransonware, os backups também foram afetados,
> depois de muito copiar e tentar salvar alguma coisa, consegui um arquivo de
> backup feito pelo pgdump, Ele está compactado no Format Custom.
>


Com o próprio pg_restore[1] você pode converter o formato pra plain.

Te liga nesse exemplo aonde eu crio uma tabela generica qualquer:
$ *psql*

Expanded display is used automatically.
psql (9.6.4)
Type "help" for help.

sebastian=# *create table foo (id serial primary key, nome text);*
CREATE TABLE
sebastian=# *insert into foo (nome) select 'Random name ' ||
generate_series(1,1000*random()::NUMERIC);*
INSERT 0 156
sebastian=# \q


Depois eu faço um dump dela no formato custom:

$ *pg_dump -Fc -f dump.custom -t foo*

Depois listo o conteudo dela:

$ pg_restore --list dump.custom
;
; Archive created at 2017-09-11 13:03:33 -03
; dbname: sebastian
; TOC Entries: 9
; Compression: -1
; Dump Version: 1.12-0
; Format: CUSTOM
; Integer: 4 bytes
; Offset: 8 bytes
; Dumped from database version: 9.6.4
; Dumped by pg_dump version: 9.6.4
;
;
; Selected TOC Entries:
;
200; 1259 74382 TABLE public foo sebastian
199; 1259 74380 SEQUENCE public foo_id_seq sebastian
2577; 0 0 SEQUENCE OWNED BY public foo_id_seq sebastian
2451; 2604 74385 DEFAULT public foo id sebastian
2572; 0 74382 TABLE DATA public foo sebastian
2578; 0 0 SEQUENCE SET public foo_id_seq sebastian
2453; 2606 74390 CONSTRAINT public foo foo_pkey sebastian

Depois converto o dump custom pra o formato plain:

$* pg_restore -Fc dump.custom -f dump.sql*
$* file dump.sql*
dump.sql: ASCII text

Veja se o pg_restore te ajuda com o teu problema.

1. https://www.postgresql.org/docs/current/static/app-pgrestore.html

--
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Índices em SSD

[Sebastian Webber]

Em ter, 5 de set de 2017 às 17:26, Neto pr  escreveu:

Olá pessoal!

Estou utilizando atualmente postgresql 10,Proc Xeon 2.8GHz/4-core-
8gb Ram, SO Debian 8.


Rodando a beta em produção? ou apenas testes de benchmark?


Estou planejando migrar alguns índices de um disco Sata 7200 rpm, para
um SSD, devido a maior velocidade de leitura desses discos.
Infelizmente as tabelas não podem ser migradas, pois não haveria
espaco no SSD para tanto.


Isso seria uma coisa interessante, assim como usar o ssd como cache desse
disco sata 7.2k rpm.

Isso é relativamente fácil de fazer com zfs, dá uma olhada[1].



Inicialmente estava pensando em migrar somente os índices que seriam
maiores  que o SHARED_BUFFER do meu servidor, pois acredito que
indices menores que o SHARED_BUFFER não valeria a pena.


Tem um grande depende aqui: seria ideal ter memória o bastante pra isso,
pelo menos pra cachear esses datafiles antes de bater no disco. Classo que
isso não iria impedir de ler o disco, mas ia fazer diferença depois que os
dados estão no cache.


Alguem já utilizou essa estratégia de deixar a tabela em um tipo de
disco (por exemplo Hdd)  e indices em outro (SSD por exemplo)?


Já utilizei raids diferentes e tive um desempenho interessante.


Será que reduziria o tempo de execucao das queries?


Honestamente, depende das consultas que rodam no banco. Conta mais detalhes
do teu ambiente e ap e quais tipos de consultas são mais frequentes. Com
isso da pra ser mais acertivo.


O ambiente de execucão é um Data warehouse, e a maioria dos SQLs sao
consultas, quase nada de atualizacões.


Massa e quais parametros vc ajustou no postgresql.conf?


Saudacões



[]'s

   1. http://evol-monkey.blogspot.com.br/2017/08/postgresql-on-zfs.html
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Integração MSSQL

[Sebastian Webber]

Em sex, 1 de set de 2017 às 16:49, centrisco...@gmail.com <
centrisco...@gmail.com> escreveu:

> Qualquer banco de dados pode ser acessado pelo Postgres usando o FDW?
> O Firebird estaria nessa lista?
>

Depende do banco, alguns já tem pronto outros teria que implementar.

o firebird tem um que está sendo desenvolvido[1].

Dá uma olhada:
https://wiki.postgresql.org/wiki/Foreign_data_wrappers

[]'s

[1] https://github.com/ibarwick/firebird_fdw/

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

Re: [pgbr-geral] Servidor Backup

[Sebastian Webber]

Em qui, 31 de ago de 2017 às 10:13, <j...@inbraco.com> escreveu:

> Senhores tenho dois locais escritório e fábrica
>
> Nosso servidor S1 está no escritório e é acessado pela fábrica através de
> uma VPN.
>
> Temos muitos problemas de queda de internet
>
> É possível ter um servidor na fábrica S2 que seria utilizado na falta de
> comunicação e que atualize os dados em S1  quando a comunicação se
> normalizar.
>


Faria mais sentido o contrário, não?

Deixe o servidor na fabrica e uma replica no escritório. No pior cenário vc
tem uma copia dos dado assincrona no escritório.

[]'s

--
Sebastian Webber
https://swebber.me
___
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]

[Sebastian Webber]

Em 6 de julho de 2017 11:10, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:


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.


Legal isso. Não me liguei que o CURRVAL dependia do NEXTVAL.

sebastian=# select currval('teste');
ERROR:  currval of sequence "teste" is not yet defined in this session

[]'s


-- 
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>?  Dá uma olhada no que eu ando
aprontando: http://swebber.me
___
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]

[Sebastian Webber]

Em 5 de julho de 2017 15:51, Flávio Silveira <f...@terra.com.br> escreveu:


Boa tarde,

  Como leigo que sou, num caso desse uma CTE não resolveria também?


Essa é uma excelente idéia!

WITH pedido AS (
INSERT INTO pedido(data) VALUES (now()) RETURNING id;
) INSERT INTO item
(fk_pedido, produto, quantidade, valor)
VALUES (pedido.id, 'Camiseta', 2, 25.00),
   (pedido.id, 'Calça’, 2, 40.70),
   (pedido.id, 'Meia’, 5, 5.90),
   (pedido.id, 'Camisa’, 1, 60.00);


PS: Não testei, mas a sintaxe é mais ou menos essa aí!


-- 
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>?  Dá uma olhada no que eu ando
aprontando: http://swebber.me
___
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]

[Sebastian Webber]

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.

Dá uma olhada na sintaxe do INSERT[1] pq o mesmo permite que tu retorne o
valores inseridos.

Fazer isso num DO[2] block ia ser ainda mais fácil.


[1] https://www.postgresql.org/docs/current/static/sql-insert.html
[2] https://www.postgresql.org/docs/current/static/sql-do.html

-- 
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>?  Dá uma olhada no que eu ando
aprontando: http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Conteúdo de logs para arquivo CSV

[Sebastian Webber]

Em 10 de maio de 2017 11:11, Tiago José Adami <adam...@gmail.com> escreveu:

> Bom dia!
>
> Bom dia!


> Em um servidor na Amazon rodando PostgreSQL 9.4.9 apresenta um
> comportamento estranho - ao menos para mim: ao invés de gravar todo o
> conteúdo em um arquivo com extensão "log", um arquivo sem extensão é
> criado com tamanho 0 bytes e tudo é redirecionado para um outro
> arquivo com extensão "csv".
>

Roda no psql:


\x
select * from pg_settings where name = 'log_destination';



>
> Não devo estar percebendo corretamente o valor de alguma configuração,
> mas tenho outros servidores com os mesmos parâmetros (aparentemente) e
> estão armazenando os logs corretamente.
>
> Alguém poderia revisar minhas configurações, por gentileza?
>
>
> log_destination = 'stderr'
> logging_collector = on
> log_directory = '/pg_log'
> log_filename = 'postgresql-%a.log'
> log_truncate_on_rotation = on
>
> client_min_messages = log
> log_min_messages = warning
>
> log_min_error_statement = error
> log_min_duration_statement = 1
> log_connections = on
> log_disconnections = on
> log_lock_waits = on
> log_timezone = 'UTC'
>
>
> Lista de arquivos na pasta /pg_log de hoje:
>
> -rw--- 1 postgres postgres  402K May 10 14:04
> postgres-2017-05-10_00.csv
> -rw--- 1 postgres postgres 0 May 10 00:00
> postgres-2017-05-10_00
>
>
>
> TIAGO J. ADAMI
> _______
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>?  Dá uma olhada no que eu ando
aprontando: http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] COPY TO no servidor EXPORTAR

[Sebastian Webber]

2017-04-20 18:55 GMT-03:00 POWER Informática <
power.informatica@gmail.com>:

> Pessoal to apanhando aqui:
>

Olá, bom dia!


>
> Ambiente:
> Linux Ubuntu  / Postgresql 9.6.1 x86  / PHP Version 5.6.29
>
> A ideia é a seguinte queria salvar todas as tabelas do banco em uma pasta
> 'export/' do servidor (inicialmente rodando localhost) depois na web. Fiz
> alguns testes com PHP, li manual[1] e estou tendo dificuldades, o resultado
> do processo esta assim:
>
> $sqltab = "COPY tipopag TO 'http://localhost:8080/2017/ad
> mc/export/tipopag.csv' DELIMITERS ';' CSV HEADER ;"
>

Aqui, o endereço precisa ser um diretório no filesystem. Tente apontar o
diretório do servidor web (algo como /var/lib/http/html/admc/export).

-- 
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>?  Dá uma olhada no que eu ando
aprontando: http://swebber.me
___
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: RES: RES: PostgreSQL ataque???

[Sebastian Webber]

Em 20 de abril de 2017 10:15, Rafael Cruz <tc...@viaconect.com> escreveu:

> Senhores, bom dia
>
>
>
> Sou iniciante em PG, leio os e-mails mais não tenho nenhum conhecimento do
> banco, a não ser o básico mesmo, criar tabela, etc. Hoje comercialmente
> trabalho com FB
>
> Estamos iniciando um novo projeto para a prefeitura da cidade, e uma das
> ideias iniciais é trabalhar com PG. Alguém com mais experiência pode me dar
> um direcionamento de como configurar o SGBD de forma corretae segura, ou
> onde posso encontrar material ou alguma empresa que ofereça um curso mais
> avançado.
>
>
>
> Valeu galera... abraço a todos
>


Rafael,

pra começar, não sequestre a thread com outras duvidas.

Manda outro email com mais detalhes do teu ambiente que eu te ajudo.

-- 
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>?  Dá uma olhada no que eu ando
aprontando: http://swebber.me
___
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

[Sebastian Webber]

Em 7 de março de 2017 15:24, William Ivanski <william.ivan...@gmail.com>
escreveu:

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

Isso não é bem verdade. PGday é um dia pra falar de PostgreSQL. Pessoas e
empresas usam essa bandeira pra fazer um evento. Eu acho que conta como
pgday, mesmo que não seja um dia inteiro.

Todo caso, parabéns!

-- 
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>?  Dá uma olhada no que eu ando
aprontando: http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Perder Dados

[Sebastian Webber]

Em 6 de fevereiro de 2017 15:10, Forsell - Erlon <fors...@forsell.com.br>
escreveu:

>
> Em 06/02/2017 15:04, Ivo Sestren Junior escreveu:
>
> Não pode ser problema de transação?
> Seu software ainda não fez o commit ou por algum motivo o mesmo executou o
> rollback?
>
> >> Já perdemos dados mesmo sem ter transação, e chegou a imprimir o danfe,
> ou seja, por algum momento a informação estava no banco de dados.
> E mesmo em casos sem transação, por questão de segundos a informação
> estava no banco de dados, a hora que reinicia o sistema ou fecha a tela e
> volta a informação já não está mais lá.
>

Qual são os detalhes do ambiente? o que há nos logs do banco? como você
pode simular o problema?


> acontece 1 vez ao mes em um cliente no máximo
>
e agora começou a acontecer em outro cliente, em outro sistema onde a
> movimentação é muito maior está mais frequente, 1 ou 2x na semana,
> do que já identificamos, de sumir registros.
>

Volto a perguntar: qual é a versão que você utiliza?

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Perder Dados

[Sebastian Webber]

Em 6 de fevereiro de 2017 14:41, Forsell - Erlon <fors...@forsell.com.br>
escreveu:

> Alguém já teve problema de perder dados do banco de dados?
>

Já sim, principalmente com falha de hardware.


>
> Tivemos casos de nota fiscal emitida, com danfe e tudo, e o registro da
> nota simplesmente já depois que sair da tela do sistema sumir da base de
> dados.
>

E como sua app persiste os dados?


>
> Tem alguma versão do postgres que está com problema, alguém já passou por
> essa situação?
>

Acho pouco provavel. Qual é a versão que vc está utilizando?


>
> A uns 3 meses era só um cliente, agora apareceu mais um que começou sumir
> informação


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Profissional PostgreSQL

[Sebastian Webber]

Em 13 de janeiro de 2017 11:11, Vinícius Aquino do Vale <
aquino.v...@gmail.com> escreveu:

> Olá Pessoal,
>
> Estou a procura de um profissional junior/pleno em PostgreSQL para
> trabalhar alocado em um cliente em São Paulo, próximo a Pinheiros (metro
> Pinheiros).
>
>
> Caso conheçam alguém que esteja a procura de emprego, favor me avisar.
> Fico muito grato, e desculpa se aqui não for o lugar para isso.
>

Estou divulgando isso na DBA Brasil do telegram.

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] armazenar Plano execução

[Sebastian Webber]

Em 13 de janeiro de 2017 10:57, Euler Taveira <eu...@timbira.com.br>
escreveu:

> On 13-01-2017 01:42, Neto pr wrote:
> > Em 13 de janeiro de 2017 01:22, Euler Taveira <eu...@timbira.com.br>
> escreveu:
> >> On 12-01-2017 20:03, Neto pr wrote:
> >>> Se alguem tiver alguma sugestao de como eu poderia armazenar a saida
> >>> do explain analyse no sgbd diretamente, seria otimo, mas gostaria que
> >>> isso fosse de forma granular, ou seja, cada item do comando explain,
> >>> em campos especificos (nao necessariamente todos os itens)
> >>>
> >> Que tal modificar o auto_explain e salvar direto em uma tabela do banco?
> >>
> > A principio nao consegui sacar como fazer isso.
> > Pelo que vi o auto-explain permite alterar o formato de Saida (xml,
> > json, text), duracao da query para se registrar log e mais algumas
> > configuracoes relacionadas ao registro de logs em arquivo.
> > Caso tenha como alterar para salvar direto no banco, me interessa saber.
> >
> Eu não disse configurar e sim modificar. Isso significa que você terá
> que alterar o código fonte.
>

Complementando o email do Euler, dê uma olhada no contrib
pg_stat_statements[1]: Ele armazena as consultas executadas na base de
dados configurada. Talvez isso dê um idéia de como modificar o código pra
fazer os 2.

Outra sugestão que te dou é armazenar a saida do explain como json numa
coluna do tipo json[2] ou jsonb. tem várias funções pra pesquisar/manipular
o tipo. para o xml[3] é parecido, só acho fazer as queries com xpath mais
chatas.

happy coding!

[1] https://www.postgresql.org/docs/9.4/static/pgstatstatements.html
[2] https://www.postgresql.org/docs/current/static/datatype-json.html
[3] https://www.postgresql.org/docs/current/static/datatype-xml.html




-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Temporary File (work_mem x effective_cache_size)

[Sebastian Webber]

Em 2 de janeiro de 2017 14:40, Júlio César Martini <juliomart...@gmail.com>
escreveu:

> Caros,
>
> Estive analisando o log do meu PostgreSQL e de vez em quando da um
> mensagem de temporary file aparentemente quando roda uma SQL.
>
> Já aumentei o work_mem e o effective_cache_size e mesmo assim não
> resolveu.
>

effective_cache_size não tem a ver com isso.


> Seria mesmo esses dois parâmetros que deveria mexer?
>

A principio apenas o work_mem. Dá uma olhada aqui pra entender como
funciona[1] e também a doc[2].


>
> Atualmente essa SQL roda muito rápida e volta poucos registros.
>
> temporary file: path "base/pgsql_tmp/pgsql_tmp13773.449", size 5141632
>

Se essa consulta é muito frequente eu sugiro aumentar esse valor.

[1]
https://www.depesz.com/2011/07/03/understanding-postgresql-conf-work_mem/
[2]
http://www.postgresql.org/docs/9.6/static/runtime-config-resource.html#GUC-WORK-MEM

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Armazenamento e consulta XML

[Sebastian Webber]

Em 17 de dezembro de 2016 16:38, Fabio Systema <fabiosyst...@gmail.com>
escreveu:

> Boa Tarde colega da lista,
>
> Estou fazendo uma analise, analise esta que consiste em armazenar arquivos
> XML em um banco de dados postgresql, gostaria de saber se existe a
> possibilidade de fazer consultas em campos com datatype xml, algo como
> XQL[1].
>

Dê uma olhada nisso[1], faça seus testes e volte com suas dúvidas. :)

[1] https://www.postgresql.org/docs/current/static/datatype-xml.html


[]'s


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ORDER BY errado

[Sebastian Webber]

2016-12-15 14:33 GMT-02:00 Rogerio Bassete <roge...@microwork.inf.br>:

> Olá,
>
> Estou com um conjunto de registros que não ordena corretamente, já testei:
> - em banco de dados com encoding LATIN1, UTF-8;
> - Com PostgreSQL 9.1 e 9.3;
>

Dá uma olhada nesse post[1] e depois me comenta as configurações de collate.

[1]
http://swebber.me/blog/2013/05/16/corrigindo-problema-ordenacao-postgresql-rhel6/

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PgTune x PGConfig Opiniões

[Sebastian Webber]

Em 25 de novembro de 2016 15:47, Eduardo Az - EMBRASIS <
eduard...@embrasis.com.br> escreveu:

> Pessoal, boa tarde
>

Opa!


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


Esse aí eu assino em baixo, literalmente. :)


>
>
> 2) http://pgtune.leopard.in.ua
>
> São realmente boas? As configurações mostradas tem coerência?
>

Ambas são baseadas no pgtune. o pgconfig tem alguns extras baseado na minha
experiencia e de outros colegas da comunidade. Constantemente eu estou
atualizando


>
> 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".
>

Eu criei o PGconfig pra ser uma ferramenta de sugestão de tuning ideal, não
pra substituir o DBA. Os profiles de lá tentam sugerir a melhor config pra
cada ambiente, mas na prática eu recomendo ele como ponto de partida.
muitas vezes eu comecei dele e fiz os ajustes necessários de cada ambiente.

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_data em uma versão e binarios em outra

[Sebastian Webber]

Em 23 de novembro de 2016 12:10, Charles Viana <charles.vi...@gmail.com>
escreveu:

> Pessoal,
>
> Fui atender uma crise de um sistema que eu não faço a gestão. Quando fui
> verificar a pasta data o arquivo PG_VERSION esta com com "8.2", mas o
> binários do postgres estava a 8.4.11.
>
> Segundo os administradores do ambiente já executa assim há vários anos.
>

Fico curioso se nessas versões antigas isso era testado.


>
> Segundo eles o Banco havia sido atualizado mas não consegui identificar,
> se foi feito um pg_upgrade o arquivo PG_VERSION seria alterado ?
>

Segundo o release notes[1], o pg_upgrade foi disponibilizado na 9.0 porém
anteriormente ele foi chamado de pg_migrator[2] e esse cara suportava
versões mais antigas.


>
> Qual o risco de executar o pg_data na versão 8.2 e os binários na 8.4.11 ?
>

Qual é o tamanho da base? por que não executas apenas o dump/restore ?


>
> O arquivo PG_VERSION é que determina qual seria a versão do pg_data ?
>

> Tem outra forma de verificar isso ?
>

o que te retorna do comando abaixo?

SELECT version();



>
> OBS: No caso da crise o sistema operacional é que esta indisponível, mas
> aproveitei para verificar algumas coisas do BD e achei muito estranho essa
> configuração.
>

Eu recomendo mesmo que seja criado outra máquina pra já aproveitar e deixar
o SO mais atualizado.




[1] https://www.postgresql.org/docs/current/static/release-9-0.html
[2] http://pgfoundry.org/projects/pg-migrator


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PG Restore demorando muito

[Sebastian Webber]

Em 18 de novembro de 2016 09:45, Marcell Ribeiro <marcell.ribe...@gmail.com>
escreveu:

> /usr/local/bin/pg_restore -U usuario -d banco -v
> /disco1/backup_andamento.tar
>
> Já testei com -j e sem, não vi diferença nenhuma. Não uso compressão
> durante o dump por que li que algumas vezes pode dar problema.
>

E quantos jobs tu colocou? talvez um número pra começar seja de 4 a 8.
Depende mesmo do teu ambiente e das tuas tabelas.




-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PG Restore demorando muito

[Sebastian Webber]

Em 18 de novembro de 2016 10:25, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:


> Numa situação de restore esse tuning é recomendado. após o restore não faz
>> sentido deixar essas configurações.
>>
>
> Mas a minha colocação é justamente durante o processo. Durante esse
> processo pode ocorrer algum problema com as outras databases, dependendo do
> caso, não sei se vale a pena correr o risco.
>

Sem dúvida é algo a se considerar. O ambiente do colega vai sugerir se isso
é ou ideal.

No fim, não dá pra fugir daquela velha regra de ouro: "pra aumentar o
desempenho, em algum momento, vamos diminuir a segurança".


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PG Restore demorando muito

[Sebastian Webber]

Em 18 de novembro de 2016 09:42, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:

>
>
> 2016-11-18 9:35 GMT-02:00 Sebastian Webber <sebast...@swebber.me>:
>
>>
>>
>> Em 18 de novembro de 2016 09:08, Marcell Ribeiro <
>> marcell.ribe...@gmail.com> escreveu:
>>
>>> Bom dia galera, estou fazendo um pg restore mas está demorando cerca de
>>> 7 horas pra restaurar apenas um tar de 60gb,
>>>
>>
>>
>> Quais parametros tu usou na chamada do pg_restore?
>>
>>
>>>
>>> Que parâmetros eu poderia mudar no postgresql.conf pra melhorar isso? Já
>>> pesquisei no google e alterei alguns mas ainda não deu certo não sei por
>>> que.
>>>
>>
>>
>> Dá uma olhada nisso[1].
>>
>> [1] https://gist.github.com/fabriziomello/dd0ad27fc66ea34474dfdb
>> f918d6d230
>>
>
> Só fique atento, caso você tenha outras bases nesse servidor os parâmetros
> abaixo podem deixar as outras bases vulneráveis a corrompimento.
>
> fsync = off synchronous_commit = off
>
>
Numa situação de restore esse tuning é recomendado. após o restore não faz
sentido deixar essas configurações.



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PG Restore demorando muito

[Sebastian Webber]

Em 18 de novembro de 2016 09:08, Marcell Ribeiro <marcell.ribe...@gmail.com>
escreveu:

> Bom dia galera, estou fazendo um pg restore mas está demorando cerca de 7
> horas pra restaurar apenas um tar de 60gb,
>


Quais parametros tu usou na chamada do pg_restore?


>
> Que parâmetros eu poderia mudar no postgresql.conf pra melhorar isso? Já
> pesquisei no google e alterei alguns mas ainda não deu certo não sei por
> que.
>


Dá uma olhada nisso[1].

[1] https://gist.github.com/fabriziomello/dd0ad27fc66ea34474dfdbf918d6d230

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Autovacuum não é o inimigo! [Ajuda pra revisar tradução]

[Sebastian Webber]

Em 14 de novembro de 2016 16:01, Daniel Luiz da Silva <
daniel.si...@ipm.com.br> escreveu:


> Valeu Seba,
>

:)


>
> Ficou boa tradução, a ideia principal ficou acessível para compreensão.
> Só não entendi a frase "...A média de densidade da folha é a porcentagem
> do uso da página de índice de folha".
>

Essa frase (The average leaf density is the percentage of index leaf page
usage) foi um desafio. =/

Alguma outra sugestão?


> Isso significa que se a densidade do meu índice for muito baixa, a
> ocupação da folha será menor?
>

Confesso que não sei responder essa mas já coloquei na minha lista dar uma
olhada sobre o algoritmo do BTREE[1] e post do Use the index Luke[2].


[1] https://en.wikipedia.org/wiki/B-tree
[2] http://use-the-index-luke.com/sql/anatomy/the-tree

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Autovacuum não é o inimigo! [Ajuda pra revisar tradução]

[Sebastian Webber]

Em 14 de novembro de 2016 15:24, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:


>
> Eu li rapidamente e não achei nada que desabonasse sua tradução :)
>

Valeu! :)


> Mas não entendi porque você insistiu em chamar de AutoVACUUM, no artigo
> original está bem bonitinho "Autovacuum", mas é pessoal ;)
>

Eu queria dar enfase as palavras Auto e VACUUM mas, pensando melhor, acho
que na tradução não é o melhor lugar pra impor essa minha "vontade". :p


> Muito obrigado pela sua iniciativa !
>

Valeu cara! Tem outros que eu quero traduzir assim que aplicar essas regras
do Autovacuum no pgconfig.org.


BTW, preciso de idéias de como implementar isso no pgconfig.org. :)

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Autovacuum não é o inimigo! [Ajuda pra revisar tradução]

[Sebastian Webber]

Pessoal,

achei um artigo incrivel[1] no blog da citus data que fala do autovacuum.
Entrei em contato com os caras e pedi autorização pra traduzir ele pra
pt-br.

Fiz a tradução e coloquei no meu blog[2].

Alguma alma caridosa poderia dar uma revisada e me ajudar a arrumar
qualquer erro de tradução?

[]'s

[1] https://www.citusdata.com/blog/2016/11/04/autovacuum-not-the-enemy/
[2] http://swebber.me/blog/2016/11/14/autovacuum-nao-e-o-inimigo/

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PostgreSQL + AWS RDS

[Sebastian Webber]

Em 8 de novembro de 2016 11:56, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:

>
>
> A Amazon conta 3 IOPS por GB, podendo chegar a 3000 IOPS (se você utiliza
> muito IOPS ocasionalmente, a Amazon tem o Burst que independente de quantos
> IOPS você tenha, ele libera até 3000IOPS, utilizando créditos de IOPS não
> utilizados, caso use 100%, ou seja 3000IOPS, irá durar 30 minutos). [1]
>

Isso é valido apenas pra discos GP2. discos do tipo io1 tem os IOPS
dedicados conforme contrato. É importante lembrar que o througput máximo do
disco gp2 é 160mbps e do io1 é 320mbps e que cada instancia ec2 tem um
limite de troughput também (varia de tipo pra tipo).

Particularmente eu acho o burst mais prejudicial do que util.


>
> Porém se a sua aplicação necessita de mais do que 3000 IOPS, ai realmente
> você terá que utilizar o provisionamento de IOPS no disco, ou ir para uma
> instância EC2, e criar um RAID com vários volumes EBS para alcançar os IOPS
> necessários.
>
> [1] - http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/
> CHAP_Storage.html
>
>
>
Eu gosto da idéia de fazer um RAID 0 com varios volumes de gp2 de 1 tb pra
dar uma quantidade alta de IOPS e troughtput na soma de todos os volumes.
Adotar essa idéia te obriga a ter um standby que funcione a contento pois o
raid pode quebrar se apenas um dos discos falhar.

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PostgreSQL + AWS RDS

[Sebastian Webber]

Em 8 de novembro de 2016 11:18, Emanuel Araújo <eac...@gmail.com> escreveu:

> Srs.
>
> Dúvida:
>
> O serviço da Amazon RDS, no tocante ao provisionamento de IOPS (Storage e
> IOPS), faz o escalonamento de espaço de forma automática ?  Ou seja, ao
> contratar esse serviço mais o provisionamento, quando a base de dados
> chegar no limite, automaticamente eles irão escalar o armazenamento ?
>

Se eu lembro bem eles fazem o upgrade do disco via faiolver: sobem uma nova
replica com mais disco, assumem ela como master, apagam o antigo master e
recriam a replica com o mesmo tamanho.


>
> Alguém usa algo do tipo, ou sempre que precisam escalar armazenamento,
> fazem de forma manual ?
>

To pra dizer que depende. O que tu ta precisando fazer exatamente?

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tamanho real da base em disco

[Sebastian Webber]

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)


Então, eu dou uma ajustada na query que computa os tamanho dos objetos[1] e
identifico o espaço alocado:

sebastian=# \x

Expanded display is on.

sebastian=# SELECT *, pg_size_pretty(total_bytes) AS total

sebastian-# , pg_size_pretty(index_bytes) AS INDEX

sebastian-# , pg_size_pretty(toast_bytes) AS toast

sebastian-# , pg_size_pretty(table_bytes) AS TABLE

sebastian-#   FROM (

sebastian(#   SELECT *, total_bytes-index_bytes-COALESCE(toast_bytes,0) AS
table_bytes FROM (

sebastian(#   SELECT c.oid,nspname AS table_schema, relname AS
TABLE_NAME

sebastian(#   , c.reltuples AS row_estimate

sebastian(#   , pg_total_relation_size(c.oid) AS total_bytes

sebastian(#   , pg_indexes_size(c.oid) AS index_bytes

sebastian(#   , pg_total_relation_size(reltoastrelid) AS
toast_bytes

sebastian(#   FROM pg_class c

sebastian(#   LEFT JOIN pg_namespace n ON n.oid = c.relnamespace

sebastian(#   WHERE relkind = 'r'

sebastian(# AND (n.nspname <> ALL (ARRAY['pg_catalog'::name,
'information_schema'::name])) AND n.nspname !~ '^pg_toast'::text

sebastian(#   ) a

sebastian(# ) a;

-[ RECORD 1 ]+---

oid  | 16746

table_schema | public

table_name   | foo

row_estimate | 1e+06

total_bytes  | 66813952

index_bytes  | 22487040

toast_bytes  | 8192

table_bytes  | 44318720

total| 64 MB

index| 21 MB

toast| 8192 bytes

table| 42 MB


Por fim, os ~7mb que faltam são do espaço alocado no template 1, veja:

sebastian=# \l+
List of databases
-[ RECORD 1 ]-+---
Name  | postgres
Owner | sebastian
Encoding  | UTF8
Collate   | en_US.UTF-8
Ctype | en_US.UTF-8
Access privileges |
Size  | 71 MB
Tablespace| pg_default
Description   | default administrative connection database
-[ RECORD 2 ]-+---
Name  | sebastian
Owner | sebastian
Encoding  | UTF8
Collate   | en_US.UTF-8
Ctype | en_US.UTF-8
Access privileges |
Size  | 70 MB
Tablespace| pg_default
Description   |
-[ RECORD 3 ]-+---
Name  | template0
Owner | sebastian
Encoding  | UTF8
Collate   | en_US.UTF-8
Ctype | en_US.UTF-8
Access privileges | =c/sebastian  +
  | sebastian=CTc/sebastian
Size  | 6945 kB
Tablespace| pg_default
Description   | unmodifiable empty database
-[ RECORD 4 ]-+---
Name  | template1
Owner | sebastian
Encoding  | UTF8
Collate   | en_US.UTF-8
Ctype | en_US.UTF-8
Access privileges | =c/sebastian  +
  | sebastian=CTc/sebastian
Size  | 6945 kB
Tablespace| pg_default
Description   | default template for new databases



Repita os passos ai no seu cluster e me avise, ok?

[1] https://wiki.postgresql.org/wiki/Disk_Usage

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tamanho real da base em disco

[Sebastian Webber]

Em 25 de outubro de 2016 18:22, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:

>
>
> 2016-10-25 17:28 GMT-02:00 Sebastian Webber <sebast...@swebber.me>:
>
>>
>>
>> Em 25 de outubro de 2016 16:02, Cleiton Luiz Domazak <
>> cleitondoma...@gmail.com> escreveu:
>>
>>> Boa tarde.
>>>
>>> Preciso calcular o tamanho total de uma base em disco, não logicamente
>>> pela PostgreSQL.
>>>
>>
>> Dá uma olhada na função pg_database_size[1].
>>
>>
>>>
>>> Todas as bases estão criadas em cima de tablespaces, e como cada base
>>> tem a sua tablespace especifica, os temp files são criados em uma delas
>>> também. E o volume de WAL em disco é irrelevante nesse caso, deve ter uns
>>> 30 arquivos.
>>>
>>>
>> Temp files são gerados quanto algumas consultas não conseguem ser
>> ordenadas na work_mem ou em algumas tarefas de manutenção e como o nome
>> diz, são temporários. Acho que não devem fazer parte da tua conta.
>>
>>
>>>
>>> Então além do tamanho dessas tablespaces em disco, teria algo a mais a
>>> ser considerado?
>>>
>>
>> Pra calcular o tamanho da base, não acho que precise de mais nada que o
>> tamanho dos objetos, que podem ser computados com a função que citei acima.
>>
>
> Infelizmente não
>
> Tenho uma base que criei apenas para realizar esse teste, a qual em disco
> tem 1,2GB, e no PostgreSQL está com 2,4GB, mesmo rodando vacuum de tudo
> quanto é tipo.
>

Certeza que não está esquecendo nenhum esquema?


>
>
> select pg_size_pretty(pg_database_size('teste2'));
> "2410 MB"
>
>
> 1.2Gpg_tblspc (criei uma tablespace e defini como default justamente
> para isolar e saber o tamanho exato)
>
>
> teste2=# \dt+
>  List of relations
>  Schema | Name  | Type  |  Owner   |  Size   | Description
> +---+---+--+-+-
>  public | teste | table | postgres | 1200 MB |
> (1 row)
>

ok, roda isso e me mostra a saida:

SELECT tablename,
pg_size_pretty(SUM(pg_total_relation_size(quote_ident(schemaname) || '.' ||
quote_ident(tablename FROM pg_tables
GROUP BY tablename
ORDER BY  SUM(pg_total_relation_size(quote_ident(schemaname) || '.' ||
quote_ident(tablename))) DESC;



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tamanho real da base em disco

[Sebastian Webber]

Em 25 de outubro de 2016 16:02, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:

> Boa tarde.
>
> Preciso calcular o tamanho total de uma base em disco, não logicamente
> pela PostgreSQL.
>

Dá uma olhada na função pg_database_size[1].


>
> Todas as bases estão criadas em cima de tablespaces, e como cada base tem
> a sua tablespace especifica, os temp files são criados em uma delas também.
> E o volume de WAL em disco é irrelevante nesse caso, deve ter uns 30
> arquivos.
>
>
Temp files são gerados quanto algumas consultas não conseguem ser ordenadas
na work_mem ou em algumas tarefas de manutenção e como o nome diz, são
temporários. Acho que não devem fazer parte da tua conta.


>
> Então além do tamanho dessas tablespaces em disco, teria algo a mais a ser
> considerado?
>

Pra calcular o tamanho da base, não acho que precise de mais nada que o
tamanho dos objetos, que podem ser computados com a função que citei acima.
<https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral>

[]'s

[1]
https://www.postgresql.org/docs/current/static/functions-admin.html#FUNCTIONS-ADMIN-DBSIZE

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] missing chunk number 0 for toast value 343342964 in pg_toast_2619

[Sebastian Webber]

Em 3 de outubro de 2016 14:39, Zan <zan...@farmaponte.com.br> escreveu:

> Boa tarde a todos.
>
> Versão: PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc
> (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
>
> Nosso BD não está mais listando algumas tabelas internas do sistema, por
> exemplo, ao fazer select * from pg_class aparece a seguinte mensagem:
> missing chunk number 0 for toast value 343342964 in pg_toast_2619
>
> Alguém pode me dar alguma orientação sobre como resolver este problema?
>


Você tem algum backup recente do banco? esse é o jeito mais fácil de
resolver isso: recriar o cluster (com o initdb, claro) e restaurar os dados
nele.

Caso você não tenha, faça backup do diretório de dados e dos tablespaces
ANTES de fazer qualquer procedimento.

Sugestão que eu dou antes de começar é, apesar do erro, subir o banco em
single e tentar reindexar o catalogo e tentar fazer backup da base com
problemas. uma vez com o backup, faça o que sugeri antes.

Agora, caso você faça isso e não tenha efeito: eu sugiro que identifique
quais são as tabelas e linhas corrompidas pra pensarmos num plano de ação.

PS: corrupção de dados não é uma coisa comum. alguma idéia do que causou
isso?





-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Mudanças no repositório do PGDG

[Sebastian Webber]

Pessoal,

Ocorreu uma mudança nos repositórios do pgdg e o endereço dos repostórios
foi alterado.

Lembrem de baixar os rpms de configuração e reinstalar o repositório em
seus servidores. Imagino que os servidores baseados no Debian sofram do
mesmo mal.

Vejam mais em[1].

[1]
https://people.planetpostgresql.org/devrim/index.php?/archives/92-Lots-of-changes-at-yum.PostgreSQL.org.html

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Arquivos Temp

[Sebastian Webber]

2016-09-28 14:13 GMT-03:00 Antonio Cesar <cgcesarsoa...@gmail.com>:

>
>  Boa tarde,
>
> Pessoal Vocês poderiam me ajudar a diagnosticar/Reduzir os arquivos temp do 
> meru serrvidor.
> Linux debian
> Postgresql 9.2
>
>
Boa tarde.

Ajuste seus logs e identique quais consultas estão gerando esses arquivos
temporários com o pgbadger[1]. Depois que alinhar as consultas ajuste o
work_mem[2] necessário pra o usuário que a executa, o banco necessário ou
pra todos.

Caso queiras uma sugestão de valor indicado pra o work_mem e outros
parametros, dá uma olhada no pgconfig[3].

[]'s

[1] http://dalibo.github.io/pgbadger/
[2]
https://www.postgresql.org/docs/9.2/static/runtime-config-resource.html#GUC-WORK-MEM
[3] http://pgconfig.org



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

[Sebastian Webber]

Em 2 de setembro de 2016 12:02, Gustavo <gustavo.14042...@gmail.com>
escreveu:

> mais para eu fazer uma simples validação de dados BEFORE antes da
> gravaçao...  faço em SQL ou PLPgSQL ?
> é um simples if para saber se o valor é valido ou não...
>
>
Nesse caso, utilize plpgsql. Veja a doc[1] com exemplos e maiores detalhes.

[1] https://www.postgresql.org/docs/current/static/plpgsql-trigger.html


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Crash durante vacuum full

[Sebastian Webber]

Em 30 de agosto de 2016 11:36, Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com> escreveu:

> Flávio,
>
> Voltou nada mesmo
>
> Mas por que quando eu faco o script do tamanho do banco ele aparece.
>
> O resultado é em cima do SO e não dos metadados?
>


Sim, por que devido a falha que parou o servidor os metadados (catalogo)
não tem essa informação. Validar se o arquivo está no sistema operacional
ajuda a confirmar se o arquivo pode ser descartado ou não.

Eu adicionaria mais um ultimo teste: identiique a tabela teve o problema
com o vacuum full, faça um SELECT nela e revise os dados do lsof novamente.
Isso vai garantir que os arquivos em uso sejam listados. Até aonde recordo,
não há verificação dos datafiles de objetos do usuário até eles serem
necessários.

Meus 2 centavos.

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Sebastian Webber]

Em 30 de agosto de 2016 09:39, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:
>
>
> O que seria EL?  RH?
>

[Red Hat] Enterprise Linux e distros derivadas nele (Oracle Enterprise
Linux, CEntOS, etc)


>
> Eu recomendaria ou um Debian GNU/Linux, ou um *BSD.  Mas depende de muita
> coisa.


Concordo que é um opção, mas como não tenho experiência nessa "familia
Linux", não a recomendei.

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Sebastian Webber]

Em 29 de agosto de 2016 21:39, Márcio A. Sepp <mar...@zyontecnologia.com.br>
escreveu:

>
> Boa noite,
>
>
> Alguma vantagem/desvantagem em se utilizar o FreeBSD como sistema
> operacional para o servidor do PostgreSQL?
> Encontrei algumas documentações bem antigas [1] que são favoráveis ao
> FreeBSD. Eu particularmente tbm gosto mais dele. Mas estou por fora e se
> alguém tiver alguma documentação mais atualizada, por favor, me envie...
>
> [1]
> http://www.varlena.com/GeneralBits/Tidbits/perf.html#freebsd
>
>

De forma genérica eu te digo: SO bom é aquele que tu (DBA) domina.

Agora, eu tenho clientes que rodam ambientes sobre FreeBSD e funciona bem.
Assim como ambientes baseados em EL6 e EL7. Em suma, depende (do time,
expertise, histórico, por exemplo).

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Crash durante vacuum full

[Sebastian Webber]

Em 29 de agosto de 2016 07:58, Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com> escreveu:

> 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"?
>

Favor anexar os logs. (preferencialmente num serviço como o pastebin.com)


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Configurações Servidor Desenvolvimento Postgres

[Sebastian Webber]

Em 25 de agosto de 2016 10:25, Leonardo Coleraus <leona...@fricke.com.br>
escreveu:

> Bom Dia Amigos,
>
>
> Eu estou fazendo uns testes num balancete pra diminuir o tempo de consulta
> dele, mas antes gostaria de saber qual a melhor configuração pra fazer no
> *postgres.conf*, do servidor de *DESENVOLVIMENTO* pra ter um bom ambiente
> de teste, pois no meu Servidor de Produção esse balancete demora em torno
> de 1 hora pra fazer, mas quero reduzir esse tempo pra uns 20 a 30 minutos.
> Por isso que colocar deixa bem redondo o servidor pra facilitar.
>

Amigo,

Quem sabe tu não comenta mais detalhes sobre o teu ambiente e também a
consulta em questão?

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PGDay Ijuí 2016 - Submissão de Palestras

[Sebastian Webber]

Em 24 de agosto de 2016 14:53, Diogo L. V. G. Rubert <diogo.rub...@gmail.com
> escreveu:

> Pessoal, boa tarde!
>
> No dia 13 de Outubro de 2016 vai acontecer um PGDay em Ijuí/RS; Hoje foi
> aberta a submissão de palestras.
>
> - O evento vai patrocinar o deslocamento e hospedagem dos palestrantes;
> - Vai acontecer no Espaço OpenTech durante a Expoijuí Fenadi 2016, uma das
> mais tradicionais feiras de negócios do Rio Grande do Sul;
> - Será gratuito aos participantes!
>
> Mais informações no site [1]
>

Já mandei minhas propostas.

Parabéns a todos pela iniciativa! :)

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PgDay Campinas - Call for papers

[Sebastian Webber]

Em 15 de julho de 2016 16:09, Felipe Santos <felipe...@gmail.com> escreveu:

> Boa tarde!
>
> O PgDay Campinas ocorrerá no dia 06 de Outubro no Distrito de Barão
> Geraldo, dentro da Unicamp em Campinas.
>

Olá, boa noite.

Como foi/está sendo o critério de avaliação das palestras?


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Servidor utilizando muita memória

[Sebastian Webber]

Em 3 de agosto de 2016 18:08, Willian César <willian...@gmail.com> escreveu:

> Nesse caso, 14gb da memória está sendo usado pra cache, normalmente isso é
>> uma coisa boa. Tu tem algum problema de desempenho?
>>
>
>> Quais são os parâmetros que tu tem diferente do default?
>>
>>
>>
> Geralmente as reclamações de "desempenho" ocorrem na geração de
> relatórios. Na verdade são relatos dos usuários, demora para realizar
> algumas tarefas.
> Mas no servidor em si, não tenho problemas.
>

saquei.


>
>
> Existem (86 registros) diferentes. Se quiser te encaminho por e-mail.
>


joga no pastebin.com e manda o link. :)


>
>
>>
>>
>> Por curiosidade, qual é o sistema?
>>
>>  GIX COMÉRCIO.
>
>
bah, não conheço. massa saber que mais gente ta usando o elefantinho!
Eu atendo algumas empresas de ERPs, perguntei pro caso de ser algum sistema
conhecido.

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Servidor utilizando muita memória

[Sebastian Webber]

2016-08-03 10:04 GMT-03:00 Willian César <willian...@gmail.com>:

> Bom dia à todos!
>
> Estou realizando um serviço em um cliente que possui um ERP que trabalha
> com PostgreSQL 9.3.
> O servidor está virtualizado com Xen e a VM do banco de dados possui 16GB
> RAM / CentOS 6.
>
> Com o comando "free -m" o resultado é:
>  total   used   free sharedbuffers cached
> Mem: 15943  15795148   3161 52  14104
> -/+ buffers/cache:   1638  14305
> Swap: 5007 42   4965
>


Nesse caso, 14gb da memória está sendo usado pra cache, normalmente isso é
uma coisa boa. Tu tem algum problema de desempenho?

Quais são os parâmetros que tu tem diferente do default?

Tu pode comparar eles com essa query[1].


> 
>
> Devo aumentar o parâmetro "checkpoint_segments" ?
>

Normalmente ele não tem a ver com alocação de memória, mas sim com a
frequencia que está rodando o CHECKPOINT.


> 
>
> OBS.: a empresa que desenvolve o ERP não possui ninguém capacitado para
> ajudar.
>

Por curiosidade, qual é o sistema?

[1] https://gist.github.com/eulerto/450501d8ef00404e665b46a2f2a6e8e2

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Porque o UBER trocou o PostgreSQL para o MySQL

[Sebastian Webber]

Em 2 de agosto de 2016 18:30, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-08-02 18:20 GMT-03:00 Flavio Henrique Araque Gurgel <fha...@gmail.com
> >:
> >
> > Homem de verdade é aquele que toma porrada na lista internacional e passa
> > link do artigo do cara que lhe bateu.
>
> Dessa não fiquei sabendo!
>


Já está no youtube: http://bit.ly/pgcasts_03 :)



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Porque o UBER trocou o PostgreSQL para o MySQL

[Sebastian Webber]

Em 2 de agosto de 2016 16:49, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-08-02 16:41 GMT-03:00 Fábio Telles Rodriguez <fabio.tel...@gmail.com
> >:
> >
> > 2016-08-01 11:27 GMT-03:00 Flavio Henrique Araque Gurgel <
> fha...@gmail.com>:
> >>
> >> > O melhor resumo até agora me parece ser
> >> >
> http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choice-of-databases
> >
> > Esse também ficou muito bom:
> >
> http://blog.2ndquadrant.com/thoughts-on-ubers-list-of-postgres-limitations/
>
> De fato.
>
> Resumo da ópera: contrataram gente incompetente, gastaram muitos
> recursos para fazer uma porcaria funcionar em vez de aprender a usar o
> que já tinham.  Claro, tudo baseado em escolhas arquitetônicas
> absurdas.
>
> O de quase sempre, quando se usa MySQL ou NoSQL.  A exceção são os
> casos em que esses produtos são bem usados.
>

Interessante é que uma empresa com mais dados que eles (20PB) saiu do
oracle pro postgres e nimguém fez barulho. :)


[1]
https://www.youtube.com/watch?v=-SS4R1sFH3c=PLuJmmKtsV1dNE5y1gu1xpbIl3M2b7AW4D


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Porque o UBER trocou o PostgreSQL para o MySQL

[Sebastian Webber]

Pessoal,

Hoje a noite vamos fazer um PGCast sobre o caso do Uber.
Quem quiser acompanhar, pode usar essa URL:
http://bit.ly/pgcasts_03

Quanto aos fatos, eu compilei uma lista palestras, posts e tudo mais que
explicam mais o caso:

http://bit.ly/uber_facts

Acho que era isso.

[]'s

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Porque o UBER trocou o PostgreSQL para o MySQL

[Sebastian Webber]

Em 27 de julho de 2016 08:51, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> > Segue link com as informações:
> >
> > https://eng.uber.com/mysql-migration/
>
> Pra quem puder, sigam as listas internacionais onde o assunto é bastante
> destrinchado desde o momento da publicação:
> https://www.postgresql.org/list/



Dae Gurgel,  tudo bem?

você fala dessa thread[1]?


>
>
> Convém notar que alguns pontos levantados são legítimos, outros são
> discutíveis e outros são pura besteira ou, simplesmente, má engenharia.
>
> A decisão lá foi puramente de uma nova liderança que chegou na empresa e
> decidiu que era melhor pular pro MySQL.


+1


> É apenas um chute, mas acho que
> aí tem dedo da Oracle pra abraçar um contratinho logo logo, senão eles
> teriam partido pra MariaDB ou Cassandra.
>
> Sinceramente, eu os desejo muito boa sorte. Toda escolha em tecnologia
> tem pontos altos e baixos.
>

Realmente. Os caras tem um longo caminho pela frente. Só o tempo pra dizer
se foi uma escolha boa ou ruim.

[1] https://www.postgresql.org/message-id/579795df.10...@commandprompt.com

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Indicação de curos de PostgreSQL

[Sebastian Webber]

Em 26 de julho de 2016 11:08, Gustavo <gustavo.14042...@gmail.com> escreveu:

> site da Timbira esta fora do ar :(   ??
>

http://www.timbira.com.br/contato?l=pt

Posso pedir pro pessoal entrar em contato contigo, se for o caso.


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Indicação de curos de PostgreSQL

[Sebastian Webber]

Em 26 de julho de 2016 10:04, Luciana <gustavo.14042...@gmail.com> escreveu:

> Ola Senhores...
>
> Alguém poderia me indicar um bom cursos *ONLINE *de *PostgreSQL *??
>

o pessoal da timbira tem cursos online. qual é o foco?



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PgDay Campinas - Call for papers

[Sebastian Webber]

Em 15 de julho de 2016 16:09, Felipe Santos <felipe...@gmail.com> escreveu:

> Boa tarde!
>
> O PgDay Campinas ocorrerá no dia 06 de Outubro no Distrito de Barão
> Geraldo, dentro da Unicamp em Campinas.
>
> Quem tiver interesse em palestrar, favor enviar um email para:
> palest...@pgdaycampinas.com.br
>
>
Bora lá pessoal!

Já mandei sugestão de palestras.   :)



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] TRAVANDO REGISTROS

[Sebastian Webber]

Em 27 de junho de 2016 10:32, lu moraes santos <djrlumor...@gmail.com>
escreveu:

> Ola bom dia Sebastian, voce me sugere que qdo ocorrer o travamento eu deva
> executar um
>
> select * from pg_locks e analisar o conteudo do campo "mode"??
>
> e tb analisar a view pg_stat_activity???
>

exato. a idéia é saber o que está acontecendo no banco no momento desse
travamento.


>
> Grato
>
>
>
> [image: Foto]
> *LuMoraes*
> *O mais completo para seu comércio.*
>
> Em 27 de junho de 2016 10:09, Sebastian Webber <sebast...@swebber.me>
> escreveu:
>
>>
>>
>> Em 27 de junho de 2016 08:44, lu moraes santos <djrlumor...@gmail.com>
>> escreveu:
>>
>>> Bom dia a todos, eu uso o Postgres 9.5 Pro numa maquina Windows 7 64, na
>>> realidade é um terminal de vendas onde o caixa e servidor ficam na mesma
>>> maquina por se tratar de uma estrutura muito pequena.
>>> Os garcons enviam os pedidos atraves de um apk android que conecta
>>> direto com o banco, porem neste cliente quando chega um determinado momento
>>> ele trava algumas mesas, ou seja, fica impedido de enviar pedidos somente
>>> pra determinadas mesas, isto tanto pelo celular como tb pela retaguarda,
>>> para demais mesas tudo fica normal, O problema so corrigi se reiniciar o
>>> servico do postgres.
>>> Temos varios clientes que usam nossa solução , porem somente num cliente
>>> que ocorre este problema.
>>> Que atitude poderia tomar para cercar o problema ???
>>>
>>
>>
>> Bom dia,
>>
>> chegastes a verificar se o problema não é causado por algum lock[1] a um
>> objeto? É comum que a "lentidão" ocorra do lado do cliente por isso. Tu
>> podes verificar se o lock ocorre no servidor através da view pg_locks[2] e
>> pg_stat_activity[3], filtrando a coluna waiting.
>>
>> Pelas mensagens do log, você mata todas as conexões (e com isso todos os
>> locks são eliminados com o termino da mesma).
>>
>> [1] https://www.postgresql.org/docs/current/static/explicit-locking.html
>> [2] https://www.postgresql.org/docs/current/static/view-pg-locks.html
>> [3]
>> https://www.postgresql.org/docs/9.5/static/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW
>>
>> --
>> Sebastian Webber
>> http://swebber.me
>>
>> _______
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] TRAVANDO REGISTROS

[Sebastian Webber]

Em 27 de junho de 2016 08:44, lu moraes santos <djrlumor...@gmail.com>
escreveu:

> Bom dia a todos, eu uso o Postgres 9.5 Pro numa maquina Windows 7 64, na
> realidade é um terminal de vendas onde o caixa e servidor ficam na mesma
> maquina por se tratar de uma estrutura muito pequena.
> Os garcons enviam os pedidos atraves de um apk android que conecta direto
> com o banco, porem neste cliente quando chega um determinado momento ele
> trava algumas mesas, ou seja, fica impedido de enviar pedidos somente pra
> determinadas mesas, isto tanto pelo celular como tb pela retaguarda, para
> demais mesas tudo fica normal, O problema so corrigi se reiniciar o servico
> do postgres.
> Temos varios clientes que usam nossa solução , porem somente num cliente
> que ocorre este problema.
> Que atitude poderia tomar para cercar o problema ???
>


Bom dia,

chegastes a verificar se o problema não é causado por algum lock[1] a um
objeto? É comum que a "lentidão" ocorra do lado do cliente por isso. Tu
podes verificar se o lock ocorre no servidor através da view pg_locks[2] e
pg_stat_activity[3], filtrando a coluna waiting.

Pelas mensagens do log, você mata todas as conexões (e com isso todos os
locks são eliminados com o termino da mesma).

[1] https://www.postgresql.org/docs/current/static/explicit-locking.html
[2] https://www.postgresql.org/docs/current/static/view-pg-locks.html
[3]
https://www.postgresql.org/docs/9.5/static/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Invasão

[Sebastian Webber]

Em 20 de junho de 2016 18:24, Anderson Cristian <andercr...@gmail.com>
escreveu:

> log_line_prefix = '%t [%p-%l] %q%u@%d '
>


Conforme a doc[1], o parametro que mostra o host é o `%h`. Caso a conexão
estiver valendo, tu pode pegar e filtrar ela na view pg_stat_activity[2].

[1]
https://www.postgresql.org/docs/current/static/runtime-config-logging.html#GUC-LOG-LINE-PREFIX
[2]
https://www.postgresql.org/docs/current/static/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Invasão

[Sebastian Webber]

Em 20 de junho de 2016 18:03, Anderson Cristian <andercr...@gmail.com>
escreveu:

> Mas o postgresql não salva esses acessos em algum lugar com IP? Estranho
> não ter isso nos logs.
>

Isso depende de como está configurado o parametro *log_line_prefix*. Posta
o teu aí, please.


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [Reinstalar Postgres ] - versão 9.0

[Sebastian Webber]

Em 14 de junho de 2016 11:05, Daniel Luiz da Silva <daniel.si...@ipm.com.br>
escreveu:

> Bom dia,
> Senhores,
>
> Estou com um cenário delicado, gostaria de trocar ideia com alguém que já
> passou por isso.
> Fiz uma instalação do Postgres 9.0.5, através de pacote compilado, e
> guardei o pacote. Hoje necessita colocar a replicação do Bucardo para
> funcionar, porém, necessito reinstalar o Postgres com a opção --with-perl,
> além dos outros pacotes para rodar o Bucardo. Minha dúvida é com relação o
> risco para realizar essa operação, o Postgres reinstala somente a lib
> faltante ou faz a reinstalação completa? Sobre o risco dessa operação, é
> alto? ou seja, existe uma chance grande de ocorrer algum problema?
> Terei que realizar o comando ./configure --with-perl, gmake e gmake
> install, para deixar claro.
>

Se vc usar os pacotes do pgdg, isso pode não ser necessário.

Dê uma olhada nesse site:

http://yum.postgresql.org.
-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Função com retorno de vários dados

[Sebastian Webber]

Em 3 de junho de 2016 11:49, Ricardo <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
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Limpar tabelas pg_toast_XXXXXX

[Sebastian Webber]

Em 4 de maio de 2016 16:37, Ursulino Barboza <nino...@gmail.com> escreveu:

> Prezados,
>
> Alguém tem alguma experiência em limpeza de tabelas pg_toast, esta tabelas
> está vinculada a uma tabela que existe blobs.
>

Qual é o problema que vc está enfrentando que justifique esssa "limpeza"?

Qual é a versão do PostgreSQL?


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Minievento FISL

[Sebastian Webber]

Em 3 de maio de 2016 17:14, Fernando Foster <ferfos...@gmail.com> escreveu:

> Sobre o FISL tenho o interesse em ir. Alguém mais vai?
>

Eu vou ir.


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pgbench

[Sebastian Webber]

Em 29 de abril de 2016 17:20, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:

> boa tarde pessoal,
>

Boa tarde!


> estou montando  um servidor na aws com "8 cpus" e 16Gb de memória,
> utilizando Debian 8 e Postgresql 9.5.2.
> queria efetuar alguns testes de performance com o pgbench, mas nao
> encontrei um tutorial onde me da uma métrica para eu poder comprar com meus
> resultados, e se os mesmos estao satisfatórios.
>
> alguém teria alguma sugestão de testes ou um material para disponibilizar?
>

Dá uma olhada no pgbench tools[1] e nessa apresentação do Greg Smith[2].

[1] https://github.com/gregs1104/pgbench-tools
[2] http://www.westnet.com/~gsmith/content/postgresql/pgbench-intro.pdf

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Mensagens de erro com título em portguês

[Sebastian Webber]

Em 26 de abril de 2016 14:46, Joel Benelli <joel.bene...@gmail.com>
escreveu:

> Boa tarde,
>
> Tenho uma instalação do PG 9.4 em Windows, quando ocorre erro de
> constraint a mensagem retorna toda em inglês, exceto o título que ao invés
> de DETAIL retorna DETALHE, o mesmo postgresql.conf em uma máquina Linux
> retorna tudo em inglês. Já alteramos o lc_messages e todos parâmetros do
> postgresql.conf que tratam de idioma, sem resultado. Na instalação não
> setamos nenhum idioma esta por default EN.
>

Qual seria o resultado dos comandos abaixo?


SELECT version();

SELECT name, setting FROM pg_settings WHERE name ILIKE 'lc_%';


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Alterar tablespace

[Sebastian Webber]

Em 18 de abril de 2016 14:55, Danilo Silva <danilo.dsg.go...@gmail.com>
escreveu:

> Pessoal,
>

Boa tarde!


>
> Meu cluster possui apenas 1 base dados, e toda a base está em apenas uma
> tablespace.
>
> Preciso mover toda a base para uma outra partição, qual seria a melhor
> solução, criar uma outra tablespace e executar um alter database alter
> tablespace?
>

é uma opção válida. se você tem janela para manutenção eu recomendo que
você pare, extenda o disco e inicie o banco novamente, se não tem vc pode
fazer um novo tablespace em outro disco (conforme proposto) ou até, caso
use LVM, extender o volume em outro disco.

Prefira o que que for mais seguro (ou tem menos chances de falhar) antes do
mais rápido.

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Minievento Comunidade Brasileira de PostgreSQL no FISL17

[Sebastian Webber]

Em 13 de abril de 2016 15:40, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> On 13-04-2016 15:18, Fabrízio de Royes Mello wrote:
> > Pessoal,
> >
> > Aprovamos o nosso minievento [1] durante o FISL17 o qual chamaremos de
> > PGDay POA.
> >
> > Precisamos de palestrantes, então por favor enviem suas propostas [2]
> > sobre PostgreSQL pois teremos 5 (cinco) slots de 50minutos cada.
> >
> > Att,
> >
> >
> > [1] http://softwarelivre.org/fisl17/inscricoes/minieventos
> > [2] http://segue.fisl17.softwarelivre.org/
> >
>
> Complementando com algumas orientações da comissão organizadora do FISL:
>
>
> * Vocês devem programar 5 atividades como palestras e/ou paineis, que
> acontecerão sequencialmente, em um dia, e em um auditório.
>
> * Se tiver algum palestrante internacional, podemos considerar como uma
> 6a atividade e vamos colocá-la no auditório que terá tradução
> simultânea. Por exemplo, as 5 atividades vão acontecer no auditório 41F
> e a palestra do internacional no auditório 41A (onde terá tradução).
>

Será que eu conto como palestrante internacional? :P #justkidding


>
> * Todos os palestrantes devem se cadastrar no nosso sistema e todas as
> atividades também devem estar lá cadastradas até o dia 22 de abril.
> Depois que as atividades estiverem cadastradas, vocês devem nos avisar
> quais são essas atividades para que possamos confirmá-las. Essas
> atividades confirmadas estarão então pré-aprovadas e não precisarão
> participar da avaliação pública.
>

Será que temos espaço pra fazer um workshop sobre replicação? Seria irado
se tu e o @guediz conseguissem fazer uma demo daqueles videos irados de
vcs, não?


>
> * Recomendamos fortemente que as atividades tenham palestrantes
> diferentes para dar oportunidade a outros membros da comunidade
> participarem do FISL17. Todos os palestrantes ganham inscrição.
>
> * Quando a gente for montar a grade com a programação, vamos perguntar a
> vocês qual a sequência das atividades.
>
> * Vamos criar uma página para cada minievento no site do FISL17 com as
> fotos e currículos dos palestrantes, por isso precisamos que vocês nos
> enviem as fotos deles. Os currículos nós pegaremos do sistema. Já tenho
> a foto do Dickson.
>
> * Precisamos que vocês indiquem até este sábado qual será o nome do
> minievento.
>

Já está decidido né? PGDay POA, certo?


>
> * Vamos pedir pro pessoal da comunicação elaborar um banner web pra
> ajudar na divulgação com o nome do minievento, a logo da comunidade, e o
> link da página do minievento no site do FISL17.
>
>
> Sendo assim teremos o PGDay POA dentro do FISL17 em comemoração aos 10
> anos da Comunidade Brasileira de PostgreSQL.
>

isso quer dizer que não vai ter pgbr esse ano? O.o

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Minievento Comunidade Brasileira de PostgreSQL no FISL17

[Sebastian Webber]

Em 13 de abril de 2016 15:18, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> Pessoal,
>
> Aprovamos o nosso minievento [1] durante o FISL17 o qual chamaremos de
> PGDay POA.
>
> Precisamos de palestrantes, então por favor enviem suas propostas [2]
> sobre PostgreSQL pois teremos 5 (cinco) slots de 50minutos cada.
>

Eu já mandei 2 e to vendo uma terceira. :)

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Utilizando o comando "pg_resetxlog"

[Sebastian Webber]

Em 13 de abril de 2016 12:19, Tiago Lopes <lopes@gmail.com> escreveu:

> Bom dia Senhores,
>
> Estou com problemas no meu banco de dados PostgreSQL 8.4, instalado em um
> Debian.
>

Quais problemas? Poste a saida do log por favor.


>
> Preciso executar o comando "pg_resetxlog" para corrigir esse problema, mas
> parece que não foi instalado junto com o BD.
>

O que te leva a crer que rodar o `pg_resetxlog` pode resolver o problema?

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] validar telefone internacional

[Sebastian Webber]

Em 12 de abril de 2016 23:31, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:

> Pessoal,
> alguém ja precisou validar um determinando telefone  internacional se o
> mesmo é  um formato valido ou nao atraves de uma função ou regex?
>
>
Douglas,

tens alguma dificuldade em validar algum dado com uma função regex? Dê uma
olhada nessa doc[1] e veja se isso te ajuda.

Caso tenhas uma dúvida mais específica, ou tenhas tentado algo e não está
funcionando, posta os detalhes aqui pra ver como a gente te ajuda.

PS: talvez, se teu problema seja mesmo um regex que faz o que tu precisa,
dá uma olhada se esse site[2] te ajuda.

[1]
http://www.postgresql.org/docs/current/static/functions-matching.html#FUNCTIONS-POSIX-REGEXP
[2] http://regexlib.com/Search.aspx?k=phone

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_activity em Amazon RDS

[Sebastian Webber]

Em 11 de abril de 2016 10:41, Cleiton Luiz Domazak <cleitondoma...@gmail.com
> escreveu:

>
>
> 2016-04-04 13:56 GMT-03:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>
> :
>
>>
>>
>> 2016-04-04 11:23 GMT-03:00 Sebastian Webber <sebast...@swebber.me>:
>>
>>>
>>>
>>> Em 4 de abril de 2016 10:32, Cleiton Luiz Domazak <
>>> cleitondoma...@gmail.com> escreveu:
>>>
>>>> 
>>>>
>>>> Pois é, peguei a ultima versão, e o que dá pau é que dá com o RDS é a
>>>> database rdsadmin, que não existe role com acesso a ela, e com isso dá pau
>>>> no pg_activity.
>>>>
>>>
>>> Pelo que vi[1], ja tem um filtro no banco do rdsadmin. certeza que tu
>>> esta passando o parametro --rds?
>>>
>>> Posta o erro do pgsql e tb do pg_activity?
>>>
>>> [1]
>>> https://github.com/julmon/pg_activity/blob/6a65974dcc23e84aee36f2ec221711af365ee2ed/pgactivity/Data.py#L275
>>>
>>
>> Fiz isso ai mesmo, criei uma issue, até pq se eu dou um --help o
>> parâmetro --rds nem aparece, deve ser algum bug.
>>
>> Quando o pessoal lá responder posto aqui.
>>
>> Vlw a ajuda pessoal.
>>
>
> Já descobri o que rolou pessoal.
>
> Peguei um fork do projeto, que tinha na descrição que tinha suporte ao
> RDS, porém os caras não implementaram, deve ter copiado só o README :D.
>
> Só peguei o fork original do projeto e funcionou de boas.
>

Qual é o projeto que tu passou a usar? e qual estavas usando?

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Mini Eventos no FISL 17 - Último Dia!

[Sebastian Webber]

Em 8 de abril de 2016 10:15, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> On 07-04-2016 23:34, Marcio Junior Vieira wrote:
> >
> > Prorrogaram o período de inscrição para palestras para dia 22, quem
> > tiver interesse enviar, no mini-evento serão 5 palestras as não
> > aprovadas no principal podem ser sugeridas a ser adicionadas ao
> > MiniEvento , as mesmas pelo que vi devem estar inscritas no sistema de
> > submissão , ficando a cargo do cordenador no minievento a sua inclusão. !
> >
>
> Isso mesmo... pena que precisamos esperar aprovação do mini-evento,
> senão já poderiamos iniciar divulgação pra interessados em palestrar no
> FISL17.
>
>
Em fevereiro, eu tinha trocado uma idéia com o Sadi e fiquei de falar com
ele na volta das férias dele, em março. Me passei nessa.

No que posso ajudar?

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Reinício do ID de Transações

[Sebastian Webber]

Em 6 de abril de 2016 17:31, Marcio Junior Vieira <
mar...@ambientelivre.com.br> escreveu:

> 9.4
>
> posso fazer vacuumdb -fazq  é mais rápido que full ? terá o mesmo efeito
> do autovaccum  correto ?
>

roda apenas vacuumdb -vaz. revise o --help pq a opção -f é rodar o full.



> minha questão agora e tempo , se perder dados neste caso não e problema!
>
>
dump e restore é bem mais rápido.

sério. evite top-posting.


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Reinício do ID de Transações

[Sebastian Webber]

Em 6 de abril de 2016 16:17, Marcio Junior Vieira <
mar...@ambientelivre.com.br> escreveu:

> Olá Pessoal ,
>
> temos um database parou por atingir  2 bilhões de transações entre um
> AUTOVACCUM  e outro conforme limitação que vi nos docs do postgresql
>

> a recomendação e mesmo para subir sigle-mode e fazer o VACCUM FULL ?
>

Conforme já comentaram, é apenas necessário rodar um vacuum (sem o full).

>
> pergunto isso pois não preciso dos dados deste periodo e estou dispostos a
> perde-los para garantir que a aplicação suba novamente sem esperar o tempo
> do VACCUM FULL pois esta demorando estremamente ( + de 18 horas )
>

extremente tem um x. mas como falei antes, vacuum full não é necessário.
Qual é a versão do seu PostgreSQL?

>
> pensei em atualizar a tabela pg_database e o campo  AGE para o inicio do
> contator de ID de 1 milhão... alguem ja fez isso ?
>

Dump e restore é o melhor caminho! Qual é o tamanho da tua base de dados?



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_activity em Amazon RDS

[Sebastian Webber]

Em 4 de abril de 2016 10:32, Cleiton Luiz Domazak <cleitondoma...@gmail.com>
escreveu:

> 
>
> Pois é, peguei a ultima versão, e o que dá pau é que dá com o RDS é a
> database rdsadmin, que não existe role com acesso a ela, e com isso dá pau
> no pg_activity.
>

Pelo que vi[1], ja tem um filtro no banco do rdsadmin. certeza que tu esta
passando o parametro --rds?

Posta o erro do pgsql e tb do pg_activity?

[1]
https://github.com/julmon/pg_activity/blob/6a65974dcc23e84aee36f2ec221711af365ee2ed/pgactivity/Data.py#L275



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como tratar a concorrencia Update x Select

[Sebastian Webber]

Em 1 de abril de 2016 14:07, <siste...@mvsoftware.com.br> escreveu:


>
> Vou verificar aqui se mais de um usuário está usando essa rotina de Update
> por demanda, pois pode estar aí o problema.
>
>
Chegastes a monitorar as consultas lentas pra validar se o que está
acontecendo é um lock no registro ou algo especifico no sistema? Nenhuma
operação de UPDATE/DELETE vai impedir os dados de serem lidos.

Acho interessante acompanhar as consultas e ver o comportamento do banco
nos horários de travamento. Caso possível, passe a monitorar os locks
através do exemplo abaixo:

https://wiki.postgresql.org/wiki/Lock_Monitoring

[]'s

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_activity em Amazon RDS

[Sebastian Webber]

Em 2 de abril de 2016 00:07, Sebastian Webber <sebast...@swebber.me>
escreveu:


> Pelo que vi no GitHub[1], o commit que foi implementado o suporte ao RDS
> já foi feito merge. Certeza que está usando a versão mais recente?
>
> [1]
> https://github.com/julmon/pg_activity/commit/759bad22d6def7bd265794ba57105bb33306a761
>
>
O commit correto era esse:

https://github.com/julmon/pg_activity/commit/8f46c2251ee5295e34754f8a2b87a606556d3af7


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_activity em Amazon RDS

[Sebastian Webber]

Em 1 de abril de 2016 09:38, Cleiton Luiz Domazak <cleitondoma...@gmail.com>
escreveu:

> Alguém utiliza o pg_activity em bancos rodando no RDS?
>
> Por conta da estrutura de permissões do RDS ele acaba não permitindo o
> acesso default do pg_activity, já vi alguns foruns e nada funcionou.
>
> Inclusive existe um fork[1] do pg_activity para contornar essa situação e
> mesmo assim não funcionou.
>
> *[1] - https://github.com/julmon/pg_activity
> <https://github.com/julmon/pg_activity>*
>


Velho, sabe dizer quais as views que ele precisa permissão?

Lembro que é possível conectar remotamente, mas nunca cheguei a usar.

Pelo que vi no GitHub[1], o commit que foi implementado o suporte ao RDS já
foi feito merge. Certeza que está usando a versão mais recente?

[1]
https://github.com/julmon/pg_activity/commit/759bad22d6def7bd265794ba57105bb33306a761





-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

[Sebastian Webber]

2016-03-31 16:10 GMT-03:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:

> [QUERY] VACUUM FULL ANALYZE VERBOSE jbpm_byteblock
> INFO:  vacuuming "public.jbpm_byteblock"
> INFO:  "jbpm_byteblock": found 15505882 removable, 18439352
> nonremovable row versions in 4762603 pages
> DETAIL:  0 dead row versions cannot be removed yet.
> CPU 106.46s/45.32u sec elapsed 433.55 sec.
> INFO:  analyzing "public.jbpm_byteblock"
> INFO:  "jbpm_byteblock": scanned 30 of 2564994 pages,
> containing *2156123* live rows and 0 dead rows; 30 rows in sample,
> 18438821 estimated total rows
>
> [QUERY] VACUUM FULL ANALYZE VERBOSE jbpm_variableinstance
> INFO:  vacuuming "public.jbpm_variableinstance"
> INFO:  "jbpm_variableinstance": found 0 removable, 15556252
> nonremovable row versions in 283202 pages
> DETAIL:  3070018 dead row versions cannot be removed yet.
> CPU 7.59s/16.67u sec elapsed 65.72 sec.
> INFO:  analyzing "public.jbpm_variableinstance"
> INFO:  "jbpm_variableinstance": scanned 276005 of 276005
> pages, containing *12486234* live rows and *3070018* dead rows; 30
> rows in sample, 12486234 estimated total rows
>

Boa tarde!


>
> Não entendi esses números coloridos. O banco não tem nenhuma conexão, só a
> minha.
>

Nesse contexto isso não é relavante.


> O que significaria live rows no analyze? Não deveria ser igual ao
> nonremovable do vacuum full? (VERMELHO)
> Esse valor seria apenas das 30 páginas?
>

Durante a execução do ANALYZE o processo é feito por amostragem, limitadas
em até 30.000 linhas. Dessas linhas, ele estima que 12486234 são vivas (ou
seja, estão validas) e 3070018 estão mortas (ou invalidas). Isso
normalmente quer dizer que tua tabela está inchada devido ao comportamento
do MVVC.


> Se sim por que na 2a tabela está diferente já que pegou todas as páginas?
>
> Aparentemente a diferença é que apenas umas das tabelas, o analyze
acredita que tenha mais tuplas mortas do que a outra.



> Por que existem dead rows, já que passei um vacuum full na tabela ? (AZUL)
>
> Qual seria a diferença do live rows do nonremovable rows?
>

Curioso isso. Ao meu ver o processo de vacuum full deveria reescrever o
datafile e sumir com essas paginas "mortas".  Qual é a versão do seu
PostgreSQL?

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: RES: RES: Replicação !

[Sebastian Webber]

Em 22 de março de 2016 09:04, Agape World Informática Ltda <
ag...@agapeworld.com.br> escreveu:

> Acho que nao estou entendedo bem a solucao.
>
>
>
> Vamos ver se o que preciso funciona :
>
>
>
>
>
> Tenho server Linux (vai receber os dados).
>
>
>
> Tenho Maquinas Windows (vai mandar os dados).
>
>
>
> Meu cliente tem um Servidor na Empresa (Linux)
>
> Tem 06 lojas todas com Windows.
>
>
>
> Preciso mandar os dados das lojas para a Empresa, (replicar)
>
> Pois ele quer saber a posição dos dados das lojas em tempo real.
>
> Vendas, caixa, estoque, etc...
>
>
>
> Vai funcionar para isso ?
>

Amigo, POR FAVOR, não faça TOP POSTING.


Acho que seria interessante que você fizesse um LAB e validasse as soluções
uma a uma, vendo o que oferece maior custo beneficio pro seu negócio.

Infelizmente, não tem receita de bolo, a soluções que tu citou acima tem um
comportamento diferente, feitas pra resolver um problema especifico. Testar
as soluções pode apontar qual delas te atende melhor.



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PGConfig

[Sebastian Webber]

Em 19 de março de 2016 12:05, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> On 19-03-2016 11:44, Alessandro Lima wrote:
> > Para 4GB 100 connections 9.5.x o pgconfig sugere 1GB shared_buffers, 3GB
> > effective_cache_size e 41MB de work_mem
> >
> > Minha dúvida é se as 100 conexões estiverem sendo usada, serão usados só
> > de work_mem 4GB (41MB x 100),
> > não sobrando nada para o sistema operacional, shared_buffers e
> > maintenance_work_mem.
> > Minha análise está correta?
> >
>
> Está correta... o que vc precisa ter em mente é que a quantidade total
> de memória que vc deve referenciar ali no pgconfig é aquela que será
> *dedicada* para o PostgreSQL. Então se seu server tem 4GB podemos
> presumir que vc queira deixar 1GB para SO, então vc deve colocar ali 3GB
> para calcular o que será *dedicado* ao PostgreSQL.
>

Acho que isso poderia ficar como um aviso, não? Assim eu coloco um warning
(dizendo que 1gb foi tirado do calculo para o SO, e caso o servidor seja
compartilhado, deve-se preencher o valor que gostaria que fosse alocado ao
postgres).


>
> Essa questão do work_mem é bem delicada, porque se vc tiver uma situação
> bem extrema onde todas suas 100 conexões executem uma
> agregação/ordenação que precise de 41MB (exatamente, pq se exceder ele
> irá usar disco) então vc terá um problema. E também poderia ocorrer em
> um cenário ainda mais improvável dessas 100 conexoes estarem executando
> query com sub-queries que usem mais de um slot de work_mem... bom ai sim
> vc tem problema.
>

Isso é uma coisa que já discutimos aqui na lista e é quase impossível
computar com 100% de certeza. Normalmente eu uso o default do pgconfig.org
e fico acompanhando a geração de temp files vs quantidade de vcs que essas
queries rodam. quando é frente eu aumento na tentativa de gerar menos
arquivos temporários.


>
> De qualquer forma é um cenário improvável mas não impossível, então a
> minha sugestão sempre é fazer uma configuração inicial (usando o
> pgconfig por exemplo), acompanhar (geracao de temp files) e ir
> ajustandoo para obter melhor performance.
>

:)


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] PGConfig

[Sebastian Webber]

Pessoal,

atualizei o pgconfig[1] pra versão 9.5 e também adicionei as versões
antigas suportadas.

Qualquer sugestão é bem vinda!

[1] http://www.pgconfig.org/

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Resincronizar replicação hot standby

[Sebastian Webber]

2016-03-18 15:49 GMT-03:00 Marcell Ribeiro <marcell.ribe...@gmail.com>:

> archive_mode = on
> archive_command = 'scp %p barman@pg-barman
> :/disco/barman/pg-banco/incoming/%f'
>

Ajusta o restore_command[1] do teu recovery.conf pra apontar pra esse
diretório do barman e tenta iniciar ele denovo.

[1] http://www.postgresql.org/docs/9.5/static/archive-recovery-settings.html


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Resincronizar replicação hot standby

[Sebastian Webber]

Em 18 de março de 2016 14:59, Marcell Ribeiro <marcell.ribe...@gmail.com>
escreveu:

> Boa tarde. Tô precisando resincronizar meu banco de replicação, faço o
> pg_start_backup, o rsync, depois o stop_backup e na hora que tento startar
> o banco de replicação aparece o seguinte:
>
>
> 2016-03-18 14:51:10 BRT LOG:  sistema de banco de dados foi interrompido;
> ?ltima execu??o em 2016-03-18 14:45:52 BRT
> 2016-03-18 14:51:10 BRT LOG:  entrando no modo em espera
> 2016-03-18 14:51:10 BRT LOG:  n?o p?de abrir arquivo
> "pg_xlog/000102460018" (arquivo de log 582, segmento 24):
> Arquivo ou diret?rio n?o encontrado
> 2016-03-18 14:51:10 BRT LOG:  registro do ponto de controle prim?rio ?
> inv?lido
> 2016-03-18 14:51:10 BRT LOG:  n?o p?de abrir arquivo
> "pg_xlog/000102460018" (arquivo de log 582, segmento 24):
> Arquivo ou diret?rio n?o encontrado
> 2016-03-18 14:51:10 BRT LOG:  registro do ponto de controle secund?rio ?
> inv?lido
> 2016-03-18 14:51:10 BRT P?NICO:  n?o p?de localizar registro do ponto de
> controle v?lido
> 2016-03-18 14:51:10 BRT LOG:  pacote de inicializa??o incompleto
> 2016-03-18 14:51:10 BRT FATAL:  o sistema de banco de dados est? iniciando
> 2016-03-18 14:51:11 BRT LOG:  processo de inicializa??o (PID 9029) foi
> terminado pelo sinal 6: Aborted
> 2016-03-18 14:51:11 BRT LOG:  interrompendo inicializa??o porque o
> processo de inicializa??o falhou
>
>
> Minha pergunta, o pg_resetxlog resolveria isso?
>

Posta teu recovery.conf

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Resincronizar replicação hot standby

[Sebastian Webber]

Em 18 de março de 2016 15:28, Marcell Ribeiro <marcell.ribe...@gmail.com>
escreveu:

> standby_mode = 'on'
> primary_conninfo = 'host=pg-hostrepl user=replicator password=pass@repl2016
> '
> trigger_file = '/tmp/postgresql.trigger'
>


no master, tu setou o archive_mode e o archive_command?  Quais valores
ficaram?


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] (sem assunto)

[Sebastian Webber]

Em 22 de fevereiro de 2016 22:03, Fernanda Forbici <
fernandaforb...@gmail.com> escreveu:

> Boa noite,
>

Boa noite!

Sugiro que você utilize o assunto para orientar sua dúvida. :D



> Criei um usuário integracao, com acesso apenas ao schema integracao. E no
> schema sistema, tenho as tabelas do sistema. Gostaria que, quando conectada
> com esse usuário integracao, se der \d não mostre a estrutura das minhas
> tabelas.
>

Tabelas do esquema integração ou de todos os esquemas?

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Streaming Replication - PostgreSQL 9.3

[Sebastian Webber]

Em 3 de fevereiro de 2016 11:35, Glauco Torres <torres.gla...@gmail.com>
escreveu:

>
>>
>> Com relação a streaming replication (PostgreSQL 9.3), estou com o
>> seguinte problema no meu servidor standby:
>>
>> *LOG:  arquivo de log restaurado "000109430010" do arquivador*
>> *LOG:  endereço da página 942/BA00 inesperado no arquivo de log
>> 000109430010, posição 0*
>> *LOG:  iniciado fluxo de WAL do principal em 943/1000 na linha do
>> tempo 1*
>> *FATAL:  não pôde receber dados do fluxo do WAL: ERRO:  segmento do WAL
>> solicitado 000109430010 já foi removido*
>>
>> Temos uma rotina que comprimi (7z) e envia blocos do WAL do Master para o
>> Standby via scp. O Standby vai aplicando conforme os mesmos vão sendo
>> disponibilizados. Esta rotina também efetua a limpeza dos segmentos que já
>> foram aplicados no Standby, para isso, utilizamos o pg_controldata para
>> verificar a posição atual de segmentos aplicados standby, com essa
>> informação pegamos todos os segmentos WAL para trás e descartamos.
>>
>> Conforme a informação do log acima, ele me diz que o segmento
>> WAL 000109430010 referencia um segmento anterior 942/BA00,
>> este já foi descartado.
>>
>
> Cara, ao que parece seu standby parou por um período ou ouve algum
> problema de comunicação.
>
>
>> É isso mesmo ? Alguém já passou por esse problema ? Vou ter que
>> re-sincronizar tudo com o basebackup ?
>>
>>
> É isso mesmo. Sim, já passei. Sim, vai ter re-sincronizar.
>

Fico curioso se o pg_rewind[1] poderia ajudar nessas horas.


[1] http://www.postgresql.org/docs/9.5/static/app-pgrewind.html




-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pgMail multiplos emails

[Sebastian Webber]

Em 29 de janeiro de 2016 12:25, Carlos Antônio Pereira (VidaUTI) <
carlosanto...@utivida.com.br> escreveu:

> Bom dia pessoal.
>
> Alguém pode me dizer se o  pgMail pode enviar um mesmo email para vários
> destinatários?
>
> Testei separando por ponto e virgura:
> select pgmail('remetente','destinatario1; destinatario2;','Teste
> PostgreSQl','Teste de envio de email PostgreSQL');
> mas não funcionou.
>

Bom dia!

Por acaso há algum erro no log do banco?

No servidor local, tu fizestes alguma configuração do servidor de email?
Pelo que vi na doc[1], isso é necessário, veja:

pgMail does not support SMTP Auth. Most of the folks that use it either set
> up a local mailserver on the database server for local queueing and then
> use that setup for any relaying required (with auth). Or, alternatively,
> there is usually a special rule made in the the /etc/mail/access (or
> equivalent) file to allow relaying from that IP used by the database
> server. Obviously, the latter option doesn't work with GMail.



[1] http://www.brandolabs.com/pgmail


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

[Sebastian Webber]

Em 14 de janeiro de 2016 18:25, Saraiva Silva <matheus.sara...@gmail.com>
escreveu:

> Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e é
> quase unanimidade entre desenvolvedores a contrariedade em deixar as regras
> de negocio no banco. Mas eu nunca vi a opinião de DBAs a respeito.
>

Sem contexto eu sinto dizer que não há resposta adequada. Todo caso, acho
que dá pra generalizar e dizer que, com base que o servidor de banco de
dados é a máquina mais porrada da empresa, deixar as regras de negocio no
banco tendem a agilizar o processamento e, por outro lado,  colocar tudo
pra rodar no banco dificulta um pouco a escalabilidade do mesmo.

Eu sou a favor de tentar colocar a logica no banco, mas nem sempre é uma
boa idéia. Por que? Primeiro pq te amarra na solução do banco de dados.
Isso não é necessáriamente ruim, mas nem sempre é do interesse da software
house.

Eu já atendi clientes em ambos os cenários: toda logica no banco, via PL e
triggers e somente repositorio. Ambos tiveram problemas de desempenho.
Deixar a logica no banco deixa o processo menos burocratizado pra resolver.
Já que deixar a logica na aplicação pode resultar em ajustes de infra e
tudo mais.

Vc tem algum caso especifico pra comentar? Algum problema real?

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_dump 9.5

[Sebastian Webber]

Em 11 de janeiro de 2016 10:10, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:

> bom dia Pessoal
>

Bom dia!


> alguém sabe se a versão do pg_dump que vem junto na instalação da versao
> 9.5 windows não aceita mais a opção -i?
> o pessoal está me relatando esse erro, sendo que na versao 9.4 funciona
> normalmente.
>


Segundo o release notes[1]:


   -

   Remove the long-ignored -i/--ignore-version option from pg_dump,
   pg_dumpall, and pg_restore (Fujii Masao)


[1] http://www.postgresql.org/docs/9.5/static/release-9-5.html


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



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Mudar a estrutura da tabela com dependencias de VIEWS

[Sebastian Webber]

Em 11 de janeiro de 2016 08:57, lu moraes santos <djrlumor...@gmail.com>
escreveu:

> Quando se muda por exemplo  o tamanho de um campo de uma tabela que exista
> views o postgres exige que se apague as dependencias altere e depois refaça
> tais dependencias, isto nao ocorre no sql server, sera que existe alguma
> solucao pra isto no pg??
>

Olá, bom dia!

Qual é a versão do PostgreSQL que você está usando?

Eu fiz um teste, conforme abaixo, e parece não ser suportado. Seria
problema apagar e recriar essa view?

$ psql
psql (9.4.5)
Type "help" for help.

sebastian=# *create table foo (id serial primary key, nome text);*
CREATE TABLE
sebastian=# *insert into foo (nome) select 'nome ' ||
generate_series(1,10);*
INSERT 0 10
sebastian=# *create view bar as SELECT id, nome from foo where id > 5;*
CREATE VIEW
sebastian=# *select * from bar;*
 id |  nome
+-
  6 | nome 6
  7 | nome 7
  8 | nome 8
  9 | nome 9
 10 | nome 10
(5 rows)

sebastian=# *alter table foo alter COLUMN nome type varchar(1000);*
ERROR:  cannot alter type of a column used by a view or rule
DETAIL:  rule _RETURN on view bar depends on column "nome"


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Mudar a estrutura da tabela com dependencias de VIEWS

[Sebastian Webber]

Em 11 de janeiro de 2016 10:37, lu moraes santos <djrlumor...@gmail.com>
escreveu:

> Eu uso a  versao 9.4 e estou testando a versao 9.5 , o exemplo que vc
> montou é exatamente isto que ocorre aqui.
> O problema é que eu tenho muitas views e qdo preciso recriar dá um
> trabalhao gigante, mas se for analisar isto nao poderia ser problema pro
> banco de dados pois a view é criada em cima da estrutura da tabela ,
> mudando a estrutura a view deveria enxergar esta nova estrutura ne, no sql
> server isto nao ocorre.
>

Amigo, pra começar, POR FAVOR, evite top-posting.

Recriar as views não é necessáriamente um problema, pra isso dê uma olhada
na visão pg_views[1].

Qual é a frequencia que você tem que alterar os tipos de dados de tabelas
do seu banco?

[1] http://www.postgresql.org/docs/current/static/view-pg-views.html

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Timeline of the primary does not match recovery target timeline

[Sebastian Webber]

2016-01-09 11:32 GMT-02:00 drum.lu...@gmail.com <drum.lu...@gmail.com>:

> Olá,
>
> Possuo o seguinte cenário:
>
> master: 192.168.100.1 (Master DB)
>
> slave1: 192.168.100.2 (Warm Standby Server)
>
> slave2(NEW SLAVE) 192.168.100.3
>
>
> Estou configurando o novo "slave2". O meu antigo "slave2" ficou OFF.
> Este novo servidor, replica do *slave1*.
>
>
Lucas,

qual é a tua idéia? fazer um escravo do slave1 ou do master? Se tua idéia é
ter 2 slaves, baseados no mesmo master, é só questão de parar o slave1,
copiar ele pro slave2, não?

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Mudar a estrutura da tabela com dependencias de VIEWS

[Sebastian Webber]

Em 11 de janeiro de 2016 14:26, Fernando Cambiaghi <cambia...@gmail.com>
escreveu:

> Recriar as views não é necessáriamente um problema, pra isso dê uma olhada
>> na visão pg_views[1].
>>
>> Qual é a frequencia que você tem que alterar os tipos de dados de tabelas
>> do seu banco?
>>
>> [1] http://www.postgresql.org/docs/current/static/view-pg-views.html
>>
>> Boa tarde Sebastian, fiquei interessado, pois tenho frequentemente este
> mesmo "problema".
> De que forma a pg_views ajudaria nestes casos?
>

A view citada tem uma coluna chamada definition. Com ela você pode pegar a
definição da view e recria-la caso seja necessário.


>
> O que faço e não é nada prático, executo o DROP VIEW...executo o ALTER
> TABLE e o CREATE VIEW...novamente. Quando uma tabela é referenciada por
> várias views, é trabalhoso controlar isso.
>

E a frequencia disso? se dá trabalho e vc faz uma vez por ano, talvez não
seja tanto trabalho.
<https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral>

Se for frequente, talvez seja mais fácil fazer uma função que automatize
isso.



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida sobre postgres_fdw + Replicação postgres Slony-I

[Sebastian Webber]

Em 6 de janeiro de 2016 11:27, Andre Ferreira <ferreiraandremen...@gmail.com
> escreveu:

> *Pessoal, alguém sabe dizer se é possível executar uma query diretamente
> num banco de dados externo, sem ter que criar uma foreign table, usando
> postgres_fdw?*
>
> Resp.: Infelizmente não é possível realizar tal ação utilizando
> postgres_fdw. Minha recomendação é que utilize o dblink dentro de uma
> função retornando uma tabela com sua consulta. Entretanto, é mais
> trabalhoso que realizar o mapeamento da foreign table e depois criar a
> consulta.
>
> Atualmente utilizo o mesmo processo com o oracle_fdw. Onde possuo uma base
> em oracle e tenho que efetuar uma consolidação de resultados em postgres.
> Pois algumas aplicações são legados e o restante são novos desenvolvimento
> em postgres.
>
>
> --
>
> *Eu uso o postgres no windows pois atendo clientes de comercio que nao tem
> muito como investir em um servidor dedicado. Eu precisaria de ferramenta
> para replicação, onde eu poderia escolher a tabela para ser replicada*
>
> Eu recomento utilizar o Slony-I (replicação unidirecional >===> Meste para
> Escravo).
> Veja este vídeo no youtube que lhe auxiliará:
> [1] https://www.youtube.com/watch?v=gHsN9hosEcM
> (recomento que faça a instalação do complemento através do strak builder).
>

Amigo,

isso tem a ver com a thread 'Dúvida sobre postgres_fdw'? Pra que abrir uma
nova com a sua resposta?



-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pg_basebackup - Não completa

[Sebastian Webber]

Em 6 de janeiro de 2016 23:01, drum.lu...@gmail.com <drum.lu...@gmail.com>
escreveu:

> Olá pessoal...
>

Boa noite!



> Rodando o comando (pg_basebackup) para poder ativar um novo slave, posso
> ver que ele executa o comando até certo ponto. Quando chega em 68 GB
> (deveria copiar /base que tem 1.7TB ) ele simplesmente para...
>


Algum erro no log do servidor remoto? que quando falo log quero dizer:
arquivos no pg_log, syslog (/var/log/messages), dmesg.


>
> Seguinte cenário:
>
> masterdb1 - Servidor Master
> slave01 - Servidor slave WARM (Estou realizando o pg_basebackup por este)
> slave02 - Novo servidor slave WARM (neste é que rodo o comando.
>
> não aparece nada nos logs do slave01 pois o postgreSQL não está rodando
> mas também não há nada nos logs do slave02 e do master
>
> nada mesmo
>
> Comando rodado:
>
> 
>
> *# (as root)*
> screen -t basebackup
> su - postgres
> cd ~/9.2/data/
>
> *# (as postgres)*
> ssh postgres@slave01 'pg_basebackup --pgdata=- --format=tar
> --label=bb_slave01 --progress --host=localhost --port=5432 --username=rep
> --xlog | pv --quiet --rate-limit 100M' | tar -x --no-same-owner
>

o host não seria masterdb1? afinal, é dele que vc está fazendo o backup.

Sem usar o formato tar, ocorre o mesmo problema? Outra coisa: por que não
rodar o comando diretamente pelo servidor remoto?

Pra testar, eu faria:

ssh postgres@slave01

screen -x

pg_basebackup -h masterdb1 -U rep --xlog -P -v -Fp -D /caminho/para/o/pgdata


Tenta aí e me avisa como fica.

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral