Re: [pgbr-geral] Configuracao do PGBouncer

2016-10-26 Por tôpico Euler Taveira 
On 26-10-2016 16:36, lu moraes santos wrote:
> Ola Euler, consigo sim
> 
[Favor responder no contexto. Evite top-posting.]

Suspeito ser algo com o host, tente:

psql -h 127.0.0.1 -U postgres -p 5432 revisa
psql -h ::1 -U postgres -p 5432 revisa


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Configuracao do PGBouncer

2016-10-26 Por tôpico lu moraes santos 
Ola Euler, consigo sim

ele cai certinho no prompt do psql , fica revisa-#

Grato


[image: Foto]
*LuMoraes*
*O mais completo para seu comércio.*

Em 26 de outubro de 2016 17:13, Euler Taveira 
escreveu:

> On 26-10-2016 13:53, lu moraes santos wrote:
> > 2016-10-26 14:49:46.955 5184 LOG S-007A7258:
> > meudb/postgres@127.0.0.1:5432  closing
> > because: connect failed (age=0)
> >
> Aparentemente o pgbouncer não consegue se conectar no postgres. Você
> consegue se conectar com o comando abaixo?
>
> psql -h localhost -U postgres -p 5432 revisa
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Configuracao do PGBouncer

2016-10-26 Por tôpico Euler Taveira 
On 26-10-2016 13:53, lu moraes santos wrote:
> 2016-10-26 14:49:46.955 5184 LOG S-007A7258:
> meudb/postgres@127.0.0.1:5432  closing
> because: connect failed (age=0)
>
Aparentemente o pgbouncer não consegue se conectar no postgres. Você
consegue se conectar com o comando abaixo?

psql -h localhost -U postgres -p 5432 revisa


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida banco replicado - tabelas temporárias

2016-10-26 Por tôpico Felipe Pereira 
Em 26 de outubro de 2016 15:36, Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com> escreveu:

> Caros,
>
> Criei uma base replicada de meu banco de produção pro pessoal de BI.
> Eles faziam elas no banco de produção, só que quando apontaram pro banco
> replicado não foi possível, pois no script que eles rodam eram criadas
> tabelas temporárias.
> Pensei que as tabelas temporárias não dessem esses erros, pois elas são
> apagadas no final da transação.
>
> Tem alguma maneira de "burlar" isso?
>
> Atenciosamente,
> Luiz carlos
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Não é possível utilizar tabelas temporárias no slave do Postgresql afaik.

Mas você pode tentar substituir os selects que geram as temporárias por
CTEs na mesma query:
https://www.postgresql.org/docs/current/static/queries-with.html

A parte que geraria sua antiga temporária vai dentro do WITH e o resto você
usa como usaria depois que a temporária já existe. Não é exatamente a mesma
coisa mas já ajuda.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Dúvida banco replicado - tabelas temporárias

2016-10-26 Por tôpico Luiz Carlos L. Nogueira Jr. 
Caros,

Criei uma base replicada de meu banco de produção pro pessoal de BI.
Eles faziam elas no banco de produção, só que quando apontaram pro banco
replicado não foi possível, pois no script que eles rodam eram criadas
tabelas temporárias.
Pensei que as tabelas temporárias não dessem esses erros, pois elas são
apagadas no final da transação.

Tem alguma maneira de "burlar" isso?

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

Re: [pgbr-geral] Configuracao do PGBouncer

2016-10-26 Por tôpico lu moraes santos 
Ola boa tarde Euler, muito grato pela atencao,

fiz as seguintes alteracoes:

NO  pgbouncer.ini:

[databases]
meudb = host=localhost port=5432 dbname=revisa

acima entao eu dei um alias chamado meudb para o banco revisa em localhost
e porta 5432

[pgbouncer]

logfile = C:\Program Files (x86)\PgBouncer\log\pgbouncer.log
pidfile = C:\Program Files (x86)\PgBouncer\log\pgbouncer.pid

;ip address or * which means all ip-s

listen_addr = localhost
listen_port = 6432
auth_type = trust
auth_file = C:\Program Files (x86)\PgBouncer\etc\userlist.txt
admin_users = postgres

acima eu coloque localhost sem estar envolvido por aspas e coloquei o
caminho completo como vc mencionou.

No userlist.txt :

"postgres" "wg091514"

obs: o firewall esta desativado

ao tentar conectar ocorre o seguinte erro que eu peguei do log:

2016-10-26 14:49:26.091 5184 LOG File descriptor limit: -1 (H:-1),
max_client_conn: 100, max fds possible: 130
2016-10-26 14:49:26.104 5184 LOG listening on ::1/6432
2016-10-26 14:49:26.104 5184 LOG listening on 127.0.0.1:6432
2016-10-26 14:49:26.104 5184 LOG process up: pgbouncer 1.7.2, libevent
2.0.21-stable (win32), adns: evdns2, tls: OpenSSL 1.0.2g  1 Mar 2016
2016-10-26 14:49:46.800 5184 LOG C-00770FF0: meudb/postgres@[::1]:51808
login attempt: db=meudb user=postgres tls=no
2016-10-26 14:49:46.954 5184 WARNING
2016-10-26 14:49:46.955 5184 LOG S-007A7258: meudb/postgres@127.0.0.1:5432
closing because: connect failed (age=0)
2016-10-26 14:50:01.858 5184 WARNING
2016-10-26 14:50:01.859 5184 LOG S-007A7258: meudb/postgres@127.0.0.1:5432
closing because: connect failed (age=0)
2016-10-26 14:50:17.042 5184 WARNING
2016-10-26 14:50:17.043 5184 LOG S-007A7258: meudb/postgres@127.0.0.1:5432
closing because: connect failed (age=0)
2016-10-26 14:50:26.101 5184 LOG Stats: 0 req/s, in 0 b/s, out 0 b/s,query
0 us
2016-10-26 14:50:31.931 5184 WARNING
2016-10-26 14:50:31.931 5184 LOG S-007A7258: meudb/postgres@127.0.0.1:5432
closing because: connect failed (age=0)
2016-10-26 14:50:46.966 5184 LOG C-00770FF0: meudb/postgres@[::1]:51808
closing because: client_login_timeout (server down) (age=60)
2016-10-26 14:50:46.966 5184 WARNING C-00770FF0: meudb/postgres@[::1]:51808
Pooler Error: client_login_timeout (server down)

GRATO



[image: Foto]
*LuMoraes*
*O mais completo para seu comércio.*

2016-10-26 13:30 GMT-02:00 Euler Taveira :

> On 26-10-2016 11:32, lu moraes santos wrote:
> > listen_addr = localhost
> > listen_port = 6432
> > auth_type = md5
> > auth_file = pgbouncer-users.txt
> > admin_users = postgres
> >
> > No userlist.txt :
> >
> pgbouncer-users.txt ou userlist.txt? Coloca o caminho completo no
> auth_file pois sem o caminho completo o carregamento do arquivo em
> auth_file depende do diretório atual. Alguma pista no log (inicie o
> serviço com -v)?
>
> > psql: ERROR:  pgbouncer cannot connect to server
> >
> Você já verificou o firewall da máquina?
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Archive não processado

2016-10-26 Por tôpico Euler Taveira 
On 26-10-2016 12:34, Cleiton Luiz Domazak wrote:
> Será que não são justamente os arquivos gerados pelo timeout que não são
> processados, por não possuírem nenhuma escrita? E acabam sendo
> arquivados somente quando é feita a "limpa" dos mais antigos?
>  
[Corte o irrelevante... Tá ficando difícil ler essa thread]

Basta olhar o arquivo de log de transação atual. Veja o comportamento
abaixo:

euler=# select pg_xlogfile_name(pg_current_xlog_location());
 pg_xlogfile_name
--
 00010001
(1 registro)

euler=# select pg_switch_xlog();
 pg_switch_xlog

 0/14EFCE0
(1 registro)

euler=# select pg_xlogfile_name(pg_current_xlog_location());
 pg_xlogfile_name
--
 00010001
(1 registro)

euler=# checkpoint;
euler=# select pg_xlogfile_name(pg_current_xlog_location());
 pg_xlogfile_name
--
 00010002
(1 registro)

euler=# select pg_switch_xlog();
 pg_switch_xlog

 0/2B0
(1 registro)

euler=# select pg_xlogfile_name(pg_current_xlog_location());
 pg_xlogfile_name
--
 00010002
(1 registro)

euler=# create table foo ();
euler=# select pg_xlogfile_name(pg_current_xlog_location());
 pg_xlogfile_name
--
 00010003
(1 registro)

Observe que apesar da chamada pg_switch_xlog(), o postgres não troca
imediatamente o arquivo atual, no entanto, alguma escrita ou checkpoint
(apesar do postgres fazer checkpoint periódicos eles podem demorar de
acordo com o que foi configurado) força essa mudança imediata (o Flavio
já comentou isso a alguns emails acima).

PS> eu não colocaria um timeout de 60s porque seria 1440 * 16 MB = 22,5
GB / dia. Se não quer perder transação use replicação ou pg_receivexlog.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Archive não processado

2016-10-26 Por tôpico Cleiton Luiz Domazak 
2016-10-26 11:55 GMT-02:00 Cleiton Luiz Domazak :

>
>
> 2016-10-26 11:45 GMT-02:00 Flavio Henrique Araque Gurgel  >:
>
>>
>>
>> Em qua, 26 de out de 2016 às 15:27, Cleiton Luiz Domazak <
>> cleitondoma...@gmail.com> escreveu:
>>
>>> 2016-10-26 11:19 GMT-02:00 Cleiton Luiz Domazak <
>>> cleitondoma...@gmail.com>:
>>>
>>>
>>>
>>> 2016-10-26 11:13 GMT-02:00 Flavio Henrique Araque Gurgel <
>>> fha...@gmail.com>:
>>>
>>>
>>>
>>> O que quer dizer com "não existissem"? Eles não cairam no seu bucket?
>>>
>>>
>>> Sim, nem no bucket e nem no archive_status, é como eles tivessem sido
>>> criados pelo banco, mas não existissem para o archive_command
>>>
>>>
>>> Pergunta : Seu banco está escrevendo?
>>> Qual o resultado de:
>>> select pg_current_xlog_location();
>>> ?
>>> Se você fizer um:
>>> select pg_switch_xlog();
>>> Há um arquivamento feito?
>>>
>>>
>>> Sim, o arquivamento está funcionando.
>>>
>>>
>> Eu não perguntei se o arquivamento está funcionando.
>> A pergunta foi: seu banco está escrevendo?
>> Por isso pedi o teste do pg_switch_xlog.
>>
>
> O que quis dizer é que estão sendo arquivados os wals, e a escrita não
> importa nesse caso, pois o timeout está setado para 60 segundos.
>
>>
>>
>>>
>>> postgres=# \x
>>> Expanded display is on.
>>> postgres=# SELECT *,
>>> postgres-# current_setting('archive_mode')::BOOLEAN
>>> postgres-# AND (last_failed_wal IS NULL
>>> postgres(# OR last_failed_wal <= last_archived_wal)
>>> postgres-# AS is_archiving,
>>> postgres-# CAST (archived_count AS NUMERIC)
>>> postgres-# / EXTRACT (EPOCH FROM age(now(), stats_reset))
>>> postgres-# AS current_archived_wals_per_second
>>> postgres-# FROM pg_stat_archiver;
>>> -[ RECORD 1 ]+--
>>> archived_count   | 147
>>> last_archived_wal| 0001011B0078
>>> last_archived_time   | 2016-10-26 11:19:04.131357-02
>>> <04%2013%2013%2057%2002>
>>> failed_count | 0
>>> last_failed_wal  |
>>> last_failed_time |
>>> stats_reset  | 2016-10-26 08:52:26.66709-02
>>> is_archiving | t
>>> current_archived_wals_per_second | 0.0166593669872578
>>>
>>> Note que não há nenhum arquivamento falho.
>>
>
> Sim, e ainda mais por isso que gostaria de entender o pq desses arquivos
> não arquivados e não falhados.
>
>>
>>> O que reparei agora, é que alguns archives desses que não são
>>> processados, acabaram sendo arquivados.
>>>
>>> # cat ../pg_log/postgresql-Wed.log | grep '0001011B006F'
>>> DETAIL: Uploading "pg_xlog/0001011B006F" to
>>> "s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B
>>> 006F.lzo".
>>> STRUCTURED: time=2016-10-26T13:10:01.724498-00
>>> <01%2072%2044%2098%2000> pid=54026 action=push-wal
>>> key=s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo
>>> prefix= seg=0001011B006F state=begin
>>> DETAIL: Archiving to "s3://bkp-postgresql-wale-loca
>>> l-hmg/wal_005/0001011B006F.lzo" complete at 1577.14KiB/s.
>>> STRUCTURED: time=2016-10-26T13:10:02.240725-00
>>> <02%2024%2007%2025%2000> pid=54026 action=push-wal
>>> key=s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo
>>> prefix= rate=1577.14 seg=0001011B006F state=complete
>>>
>>>
>>> Minha dúvida é, pq eles foram criados e não processados pelo
>>> archive_command, e agora, depois de 2 horas depois são arquivados?
>>>
>>
>> Provavelmente porque seu banco não teve escrita no período e, agora, veio
>> uma rajada de escrita qualquer. Banco que não escreve não gera wal e não
>> faz checkpoint.
>> Para forçar arquivamento, você precisa configurar a GUC archive_timeout.
>> Note que isso vai forçar o banco a arquivar 16MiB, mesmo sem necessidade se
>> o arquivo estiver parcialmente cheio.
>>
>
> No .conf que enviei, o meu archive_timeout está setado para 60 segundos.
>
>>
>>
>>>
>>> E uma curiosidade, a diretório pg_xlog, está sempre com 130 arquivos(wal
>>> segments), não importa o horário.
>>>
>>> Meu wal_keep_segments está setado para 30.
>>>
>>
>> A quantidade de arquivos depende de outras configurações, dependendo da
>> sua versão.
>> Até 9.4, depende de checkpoint_segments e checkpoint_completion_target
>> (normalmente a quantidade de arquivos é igual a
>> 2*checkpoint_segments+checkpoint_segments*checkpoint_
>> completion_target+wal_keep_segments).
>> A partir da 9.5 depende de max_wal_size.
>>
>
> Vou conferir se bate com os valores.
>
>
Será que não são justamente os arquivos gerados pelo timeout que não são
processados, por não possuírem nenhuma escrita? E acabam sendo arquivados
somente quando é feita a "limpa" dos mais antigos?


>
>
>> []s
>> Flavio Gurgel
>>
>> ___
>> pgbr-geral mailing list
>>

Re: [pgbr-geral] Configuracao do PGBouncer

2016-10-26 Por tôpico Euler Taveira 
On 26-10-2016 11:32, lu moraes santos wrote:
> listen_addr = localhost
> listen_port = 6432
> auth_type = md5
> auth_file = pgbouncer-users.txt
> admin_users = postgres
> 
> No userlist.txt :
> 
pgbouncer-users.txt ou userlist.txt? Coloca o caminho completo no
auth_file pois sem o caminho completo o carregamento do arquivo em
auth_file depende do diretório atual. Alguma pista no log (inicie o
serviço com -v)?

> psql: ERROR:  pgbouncer cannot connect to server
> 
Você já verificou o firewall da máquina?


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Configuracao do PGBouncer

2016-10-26 Por tôpico lu moraes santos 
Ola a todos , estou tentando configurar o PGBOUNCER no Windows 7 e estou
fazendo da seguinte forma:


No pgbouncer.ini:

[databases]
revisa2 = host=localhost port=5432 dbname=revisa

[pgbouncer]

logfile = C:\Program Files (x86)\PgBouncer\log\pgbouncer.log
pidfile = C:\Program Files (x86)\PgBouncer\log\pgbouncer.pid

listen_addr = localhost
listen_port = 6432
auth_type = md5
auth_file = pgbouncer-users.txt
admin_users = postgres

No userlist.txt :

"postgres" "wg091514"



No pg_hba.conf:

# IPv4 local connections:
hostall all 0.0.0.0/0md5
# IPv6 local connections:
hostall all ::0/0md5

Ai para testar se tudo esta ok eu faço:

psql -U postgres -p 6432 -d revisa2

Porem retorna:

psql: ERROR:  pgbouncer cannot connect to server

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

Re: [pgbr-geral] Archive não processado

2016-10-26 Por tôpico Cleiton Luiz Domazak 
2016-10-26 11:45 GMT-02:00 Flavio Henrique Araque Gurgel :

>
>
> Em qua, 26 de out de 2016 às 15:27, Cleiton Luiz Domazak <
> cleitondoma...@gmail.com> escreveu:
>
>> 2016-10-26 11:19 GMT-02:00 Cleiton Luiz Domazak > >:
>>
>>
>>
>> 2016-10-26 11:13 GMT-02:00 Flavio Henrique Araque Gurgel <
>> fha...@gmail.com>:
>>
>>
>>
>> O que quer dizer com "não existissem"? Eles não cairam no seu bucket?
>>
>>
>> Sim, nem no bucket e nem no archive_status, é como eles tivessem sido
>> criados pelo banco, mas não existissem para o archive_command
>>
>>
>> Pergunta : Seu banco está escrevendo?
>> Qual o resultado de:
>> select pg_current_xlog_location();
>> ?
>> Se você fizer um:
>> select pg_switch_xlog();
>> Há um arquivamento feito?
>>
>>
>> Sim, o arquivamento está funcionando.
>>
>>
> Eu não perguntei se o arquivamento está funcionando.
> A pergunta foi: seu banco está escrevendo?
> Por isso pedi o teste do pg_switch_xlog.
>

O que quis dizer é que estão sendo arquivados os wals, e a escrita não
importa nesse caso, pois o timeout está setado para 60 segundos.

>
>
>>
>> postgres=# \x
>> Expanded display is on.
>> postgres=# SELECT *,
>> postgres-# current_setting('archive_mode')::BOOLEAN
>> postgres-# AND (last_failed_wal IS NULL
>> postgres(# OR last_failed_wal <= last_archived_wal)
>> postgres-# AS is_archiving,
>> postgres-# CAST (archived_count AS NUMERIC)
>> postgres-# / EXTRACT (EPOCH FROM age(now(), stats_reset))
>> postgres-# AS current_archived_wals_per_second
>> postgres-# FROM pg_stat_archiver;
>> -[ RECORD 1 ]+--
>> archived_count   | 147
>> last_archived_wal| 0001011B0078
>> last_archived_time   | 2016-10-26 11:19:04.131357-02
>> <04%2013%2013%2057%2002>
>> failed_count | 0
>> last_failed_wal  |
>> last_failed_time |
>> stats_reset  | 2016-10-26 08:52:26.66709-02
>> is_archiving | t
>> current_archived_wals_per_second | 0.0166593669872578
>>
>> Note que não há nenhum arquivamento falho.
>

Sim, e ainda mais por isso que gostaria de entender o pq desses arquivos
não arquivados e não falhados.

>
>> O que reparei agora, é que alguns archives desses que não são
>> processados, acabaram sendo arquivados.
>>
>> # cat ../pg_log/postgresql-Wed.log | grep '0001011B006F'
>> DETAIL: Uploading "pg_xlog/0001011B006F" to
>> "s3://bkp-postgresql-wale-local-hmg/wal_005/
>> 0001011B006F.lzo".
>> STRUCTURED: time=2016-10-26T13:10:01.724498-00
>> <01%2072%2044%2098%2000> pid=54026 action=push-wal
>> key=s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo
>> prefix= seg=0001011B006F state=begin
>> DETAIL: Archiving to 
>> "s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo"
>> complete at 1577.14KiB/s.
>> STRUCTURED: time=2016-10-26T13:10:02.240725-00
>> <02%2024%2007%2025%2000> pid=54026 action=push-wal
>> key=s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo
>> prefix= rate=1577.14 seg=0001011B006F state=complete
>>
>>
>> Minha dúvida é, pq eles foram criados e não processados pelo
>> archive_command, e agora, depois de 2 horas depois são arquivados?
>>
>
> Provavelmente porque seu banco não teve escrita no período e, agora, veio
> uma rajada de escrita qualquer. Banco que não escreve não gera wal e não
> faz checkpoint.
> Para forçar arquivamento, você precisa configurar a GUC archive_timeout.
> Note que isso vai forçar o banco a arquivar 16MiB, mesmo sem necessidade se
> o arquivo estiver parcialmente cheio.
>

No .conf que enviei, o meu archive_timeout está setado para 60 segundos.

>
>
>>
>> E uma curiosidade, a diretório pg_xlog, está sempre com 130 arquivos(wal
>> segments), não importa o horário.
>>
>> Meu wal_keep_segments está setado para 30.
>>
>
> A quantidade de arquivos depende de outras configurações, dependendo da
> sua versão.
> Até 9.4, depende de checkpoint_segments e checkpoint_completion_target
> (normalmente a quantidade de arquivos é igual a 2*checkpoint_segments+
> checkpoint_segments*checkpoint_completion_target+wal_keep_segments).
> A partir da 9.5 depende de max_wal_size.
>

Vou conferir se bate com os valores.



> []s
> Flavio Gurgel
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Archive não processado

2016-10-26 Por tôpico Flavio Henrique Araque Gurgel 
Em qua, 26 de out de 2016 às 15:27, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:

> 2016-10-26 11:19 GMT-02:00 Cleiton Luiz Domazak 
> :
>
>
>
> 2016-10-26 11:13 GMT-02:00 Flavio Henrique Araque Gurgel  >:
>
>
>
> O que quer dizer com "não existissem"? Eles não cairam no seu bucket?
>
>
> Sim, nem no bucket e nem no archive_status, é como eles tivessem sido
> criados pelo banco, mas não existissem para o archive_command
>
>
> Pergunta : Seu banco está escrevendo?
> Qual o resultado de:
> select pg_current_xlog_location();
> ?
> Se você fizer um:
> select pg_switch_xlog();
> Há um arquivamento feito?
>
>
> Sim, o arquivamento está funcionando.
>
>
Eu não perguntei se o arquivamento está funcionando.
A pergunta foi: seu banco está escrevendo?
Por isso pedi o teste do pg_switch_xlog.


>
> postgres=# \x
> Expanded display is on.
> postgres=# SELECT *,
> postgres-# current_setting('archive_mode')::BOOLEAN
> postgres-# AND (last_failed_wal IS NULL
> postgres(# OR last_failed_wal <= last_archived_wal)
> postgres-# AS is_archiving,
> postgres-# CAST (archived_count AS NUMERIC)
> postgres-# / EXTRACT (EPOCH FROM age(now(), stats_reset))
> postgres-# AS current_archived_wals_per_second
> postgres-# FROM pg_stat_archiver;
> -[ RECORD 1 ]+--
> archived_count   | 147
> last_archived_wal| 0001011B0078
> last_archived_time   | 2016-10-26 11:19:04.131357-02
> <04%2013%2013%2057%2002>
> failed_count | 0
> last_failed_wal  |
> last_failed_time |
> stats_reset  | 2016-10-26 08:52:26.66709-02
> is_archiving | t
> current_archived_wals_per_second | 0.0166593669872578
>
> Note que não há nenhum arquivamento falho.

>
> O que reparei agora, é que alguns archives desses que não são processados,
> acabaram sendo arquivados.
>
> # cat ../pg_log/postgresql-Wed.log | grep '0001011B006F'
> DETAIL: Uploading "pg_xlog/0001011B006F" to
> "s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo".
> STRUCTURED: time=2016-10-26T13:10:01.724498-00
> <01%2072%2044%2098%2000> pid=54026 action=push-wal
> key=s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo
> prefix= seg=0001011B006F state=begin
> DETAIL: Archiving to
> "s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo"
> complete at 1577.14KiB/s.
> STRUCTURED: time=2016-10-26T13:10:02.240725-00
> <02%2024%2007%2025%2000> pid=54026 action=push-wal
> key=s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo
> prefix= rate=1577.14 seg=0001011B006F state=complete
>
>
> Minha dúvida é, pq eles foram criados e não processados pelo
> archive_command, e agora, depois de 2 horas depois são arquivados?
>

Provavelmente porque seu banco não teve escrita no período e, agora, veio
uma rajada de escrita qualquer. Banco que não escreve não gera wal e não
faz checkpoint.
Para forçar arquivamento, você precisa configurar a GUC archive_timeout.
Note que isso vai forçar o banco a arquivar 16MiB, mesmo sem necessidade se
o arquivo estiver parcialmente cheio.


>
> E uma curiosidade, a diretório pg_xlog, está sempre com 130 arquivos(wal
> segments), não importa o horário.
>
> Meu wal_keep_segments está setado para 30.
>

A quantidade de arquivos depende de outras configurações, dependendo da sua
versão.
Até 9.4, depende de checkpoint_segments e checkpoint_completion_target
(normalmente a quantidade de arquivos é igual a
2*checkpoint_segments+checkpoint_segments*checkpoint_completion_target+wal_keep_segments).
A partir da 9.5 depende de max_wal_size.

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Archive não processado

2016-10-26 Por tôpico Cleiton Luiz Domazak 
2016-10-26 11:19 GMT-02:00 Cleiton Luiz Domazak :

>
>
> 2016-10-26 11:13 GMT-02:00 Flavio Henrique Araque Gurgel  >:
>
>>
>>>
>>> O que quer dizer com "não existissem"? Eles não cairam no seu bucket?
>>>
>>>
>>> Sim, nem no bucket e nem no archive_status, é como eles tivessem sido
>>> criados pelo banco, mas não existissem para o archive_command
>>>
>>
>> Pergunta : Seu banco está escrevendo?
>> Qual o resultado de:
>> select pg_current_xlog_location();
>> ?
>> Se você fizer um:
>> select pg_switch_xlog();
>> Há um arquivamento feito?
>>
>
> Sim, o arquivamento está funcionando.
>
> postgres=# \x
> Expanded display is on.
> postgres=# SELECT *,
> postgres-# current_setting('archive_mode')::BOOLEAN
> postgres-# AND (last_failed_wal IS NULL
> postgres(# OR last_failed_wal <= last_archived_wal)
> postgres-# AS is_archiving,
> postgres-# CAST (archived_count AS NUMERIC)
> postgres-# / EXTRACT (EPOCH FROM age(now(), stats_reset))
> postgres-# AS current_archived_wals_per_second
> postgres-# FROM pg_stat_archiver;
> -[ RECORD 1 ]+--
> archived_count   | 147
> last_archived_wal| 0001011B0078
> last_archived_time   | 2016-10-26 11:19:04.131357-02
> failed_count | 0
> last_failed_wal  |
> last_failed_time |
> stats_reset  | 2016-10-26 08:52:26.66709-02
> is_archiving | t
> current_archived_wals_per_second | 0.0166593669872578
>
>

O que reparei agora, é que alguns archives desses que não são processados,
acabaram sendo arquivados.

# cat ../pg_log/postgresql-Wed.log | grep '0001011B006F'
DETAIL: Uploading "pg_xlog/0001011B006F" to
"s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo".
STRUCTURED: time=2016-10-26T13:10:01.724498-00 pid=54026
action=push-wal
key=s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo
prefix= seg=0001011B006F state=begin
DETAIL: Archiving to
"s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo"
complete at 1577.14KiB/s.
STRUCTURED: time=2016-10-26T13:10:02.240725-00 pid=54026
action=push-wal
key=s3://bkp-postgresql-wale-local-hmg/wal_005/0001011B006F.lzo
prefix= rate=1577.14 seg=0001011B006F state=complete


Minha dúvida é, pq eles foram criados e não processados pelo
archive_command, e agora, depois de 2 horas depois são arquivados?

E uma curiosidade, a diretório pg_xlog, está sempre com 130 arquivos(wal
segments), não importa o horário.

Meu wal_keep_segments está setado para 30.


>
>
>>
>> []s
>> Flavio Gurgel
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Archive não processado

2016-10-26 Por tôpico Cleiton Luiz Domazak 
2016-10-26 11:13 GMT-02:00 Flavio Henrique Araque Gurgel :

>
>>
>> O que quer dizer com "não existissem"? Eles não cairam no seu bucket?
>>
>>
>> Sim, nem no bucket e nem no archive_status, é como eles tivessem sido
>> criados pelo banco, mas não existissem para o archive_command
>>
>
> Pergunta : Seu banco está escrevendo?
> Qual o resultado de:
> select pg_current_xlog_location();
> ?
> Se você fizer um:
> select pg_switch_xlog();
> Há um arquivamento feito?
>

Sim, o arquivamento está funcionando.

postgres=# \x
Expanded display is on.
postgres=# SELECT *,
postgres-# current_setting('archive_mode')::BOOLEAN
postgres-# AND (last_failed_wal IS NULL
postgres(# OR last_failed_wal <= last_archived_wal)
postgres-# AS is_archiving,
postgres-# CAST (archived_count AS NUMERIC)
postgres-# / EXTRACT (EPOCH FROM age(now(), stats_reset))
postgres-# AS current_archived_wals_per_second
postgres-# FROM pg_stat_archiver;
-[ RECORD 1 ]+--
archived_count   | 147
last_archived_wal| 0001011B0078
last_archived_time   | 2016-10-26 11:19:04.131357-02
failed_count | 0
last_failed_wal  |
last_failed_time |
stats_reset  | 2016-10-26 08:52:26.66709-02
is_archiving | t
current_archived_wals_per_second | 0.0166593669872578



>
> []s
> Flavio Gurgel
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Archive não processado

2016-10-26 Por tôpico Flavio Henrique Araque Gurgel 
>
>
>
> O que quer dizer com "não existissem"? Eles não cairam no seu bucket?
>
>
> Sim, nem no bucket e nem no archive_status, é como eles tivessem sido
> criados pelo banco, mas não existissem para o archive_command
>

Pergunta : Seu banco está escrevendo?
Qual o resultado de:
select pg_current_xlog_location();
?
Se você fizer um:
select pg_switch_xlog();
Há um arquivamento feito?

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

2016-10-26 Por tôpico Fabrízio de Royes Mello 
On 26-10-2016 10:17, Sebastian Webber wrote:
> Curioso do teu problema, eu fiz um teste aqui, veja:
> 
> sebastian=# create table foo (id serial primary key, nome text);
> CREATE TABLE
> sebastian=# insert into foo (nome) select 'Nome ' ||
> generate_series(1,100);
> INSERT 0 100
> sebastian=# \dt+
> List of relations
>  Schema | Name | Type  |   Owner   | Size  | Description
> +--+---+---+---+-
>  public | foo  | table | sebastian | 42 MB |
> (1 row)
> 
> 
> 
> Até aí, tudo bem, mas quando computo o tamanho do banco, acontece algo
> diferente:
> 
>  sebastian=# select
> pg_size_pretty(pg_database_size(current_database()));
>  pg_size_pretty
> 
>  70 MB
> (1 row)
> 

Isso é normal, porque o metacomando \dt+ do psql [1] retorna o tamanho
da tabela (incluindo FSM, VM e TOAST apartir da 9.0), ou seja, não
considera índices.

Att,

[1]
http://doxygen.postgresql.org/describe_8c.html#a773ee037ae1c052551ec298504d4a970
-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

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

2016-10-26 Por tôpico Cleiton Luiz Domazak 
On Wed, Oct 26, 2016 at 10:17 AM, Sebastian Webber 
wrote:

> Curioso do teu problema, eu fiz um teste aqui, veja:
>
> sebastian=# create table foo (id serial primary key, nome text);
> CREATE TABLE
> sebastian=# insert into foo (nome) select 'Nome ' ||
> generate_series(1,100);
> INSERT 0 100
> sebastian=# \dt+
> List of relations
>  Schema | Name | Type  |   Owner   | Size  | Description
> +--+---+---+---+-
>  public | foo  | table | sebastian | 42 MB |
> (1 row)
>
>
>
> Até aí, tudo bem, mas quando computo o tamanho do banco, acontece algo
> diferente:
>
>  sebastian=# select pg_size_pretty(pg_database_size(current_database()));
>  pg_size_pretty
> 
>  70 MB
> (1 row)
>
>
> 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
>
>
-[ RECORD 1 ]+---
oid  | 18735
table_schema | public
table_name   | teste
row_estimate | 3.47e+07
total_bytes  | 1257799680
index_bytes  | 0
toast_bytes  |
table_bytes  | 1257799680
total| 1200 MB
index| 0 bytes
toast|
table| 1200 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
>
>
>
>


teste2=# \l+
List of databases
-[ RECORD 1 ]-+---
Name  | postgres
Owner | postgres
Encoding  | UTF8
Collate   | en_US.UTF-8
Ctype | en_US.UTF-8
Access privileges |
Size  | 5804 kB
Tablespace| pg_default
Description   | default administrative connection database
-[ RECORD 2 ]-+---
Name  | template0
Owner | postgres
Encoding  | UTF8
Collate   | en_US.UTF-8
Ctype | en_US.UTF-8

Re: [pgbr-geral] Archive não processado

2016-10-26 Por tôpico Cleiton Luiz Domazak 
2016-10-26 10:13 GMT-02:00 Flavio Henrique Araque Gurgel :

>
>
> Em qua, 26 de out de 2016 às 13:03, Cleiton Luiz Domazak <
> cleitondoma...@gmail.com> escreveu:
>
>> Bom dia.
>>
>> Ativei o archive e estou utilizando o Wal-e, porém hoje percebi em um dos
>> servidores de teste que um range inteiro de Wal files não foram
>> processados, eles estão na pg_xlog, e não foram processados pelo
>> archive_command e nem estão na archive_status.
>>
>> Alguém tem alguma idéia do pq?
>>
>
> Você tem que ter algo no log. Assim "a seco", difícil.
>

Exatamente é esse o meu problema , não tem nada nos logs.

>
>
>>
>> O ambiente é "PostgreSQL 9.4.9 x64 em CentOS 7 x64"
>>
>> postgresql.conf
>>
>> checkpoint_segments = 64
>> checkpoint_completion_target = 0.9
>> wal_buffers = 16MB
>> default_statistics_target = 100
>> wal_keep_segments = 30
>> max_wal_senders = 3
>> wal_level = hot_standby
>> archive_mode = on
>> archive_command = 'envdir /etc/wal-e.d/env wal-e wal-push %p'
>> archive_timeout = 60
>>
>> Uma parte dos arquivos gerados, o e-mail foi escrito 26/10/16 - 08:58:
>>
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:45
>> 0001011B0027
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:44
>> 0001011B0028
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:46
>> 0001011B0029
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:50
>> 0001011B002A
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:51
>> 0001011B002B
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:52
>> 0001011B002C
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:53
>> 0001011B002D
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:57
>> 0001011B002E
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:54
>> 0001011B002F
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:58
>> 0001011B0030
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:55
>> 0001011B0031
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:56
>> 0001011B0032
>> -rw--- 1 postgres postgres 16777216 Oct 26 07:59
>> 0001011B0033
>> -rw--- 1 postgres postgres 16777216 Oct 26 08:05
>> 0001011B0034
>> -rw--- 1 postgres postgres 16777216 Oct 26 08:04
>> 0001011B0035
>> -rw--- 1 postgres postgres 16777216 Oct 26 08:02
>> 0001011B0036
>> -rw--- 1 postgres postgres 16777216 Oct 26 08:03
>> 0001011B0037
>> -rw--- 1 postgres postgres 16777216 Oct 26 08:00
>> 0001011B0038
>> -rw--- 1 postgres postgres 16777216 Oct 26 08:01
>> 0001011B0039
>> -rw--- 1 postgres postgres 16777216 Oct 26 08:06
>> 0001011B003A
>> -rw--- 1 postgres postgres 16777216 Oct 26 08:07
>> 0001011B003B
>> -rw--- 1 postgres postgres 16777216 Oct 26 08:09
>> 0001011B003C
>> -rw--- 1 postgres postgres 16777216 Oct 26 08:08
>> 0001011B003D
>>
>>
>> Conteúdo da archive_status:
>>
>> -rw--- 1 postgres postgres 0 Oct 25 21:23 00010117005C.
>> 0028.backup.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:25
>> 0001011A00CB.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:26
>> 0001011A00CC.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:27
>> 0001011A00CD.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:28
>> 0001011A00CE.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:29
>> 0001011A00CF.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:30
>> 0001011A00D0.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:31
>> 0001011A00D1.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:32
>> 0001011A00D2.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:33
>> 0001011A00D3.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:34
>> 0001011A00D4.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:35
>> 0001011A00D5.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:36
>> 0001011A00D6.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:37
>> 0001011A00D7.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:38
>> 0001011A00D8.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:39
>> 0001011A00D9.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:40
>> 0001011A00DA.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:41
>> 0001011A00DB.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:42
>> 0001011A00DC.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:43
>> 0001011A00DD.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:44
>> 0001011A00DE.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:45
>> 0001011A00DF.done
>> -rw--- 1 postgres postgres 0 Oct 26 08:46
>> 0001011A00E0.done
>> -rw--- 1

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

2016-10-26 Por tôpico 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] Archive não processado

2016-10-26 Por tôpico Flavio Henrique Araque Gurgel 
Em qua, 26 de out de 2016 às 13:03, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:

> Bom dia.
>
> Ativei o archive e estou utilizando o Wal-e, porém hoje percebi em um dos
> servidores de teste que um range inteiro de Wal files não foram
> processados, eles estão na pg_xlog, e não foram processados pelo
> archive_command e nem estão na archive_status.
>
> Alguém tem alguma idéia do pq?
>

Você tem que ter algo no log. Assim "a seco", difícil.


>
> O ambiente é "PostgreSQL 9.4.9 x64 em CentOS 7 x64"
>
> postgresql.conf
>
> checkpoint_segments = 64
> checkpoint_completion_target = 0.9
> wal_buffers = 16MB
> default_statistics_target = 100
> wal_keep_segments = 30
> max_wal_senders = 3
> wal_level = hot_standby
> archive_mode = on
> archive_command = 'envdir /etc/wal-e.d/env wal-e wal-push %p'
> archive_timeout = 60
>
> Uma parte dos arquivos gerados, o e-mail foi escrito 26/10/16 - 08:58:
>
> -rw--- 1 postgres postgres 16777216 Oct 26 07:45
> 0001011B0027
> -rw--- 1 postgres postgres 16777216 Oct 26 07:44
> 0001011B0028
> -rw--- 1 postgres postgres 16777216 Oct 26 07:46
> 0001011B0029
> -rw--- 1 postgres postgres 16777216 Oct 26 07:50
> 0001011B002A
> -rw--- 1 postgres postgres 16777216 Oct 26 07:51
> 0001011B002B
> -rw--- 1 postgres postgres 16777216 Oct 26 07:52
> 0001011B002C
> -rw--- 1 postgres postgres 16777216 Oct 26 07:53
> 0001011B002D
> -rw--- 1 postgres postgres 16777216 Oct 26 07:57
> 0001011B002E
> -rw--- 1 postgres postgres 16777216 Oct 26 07:54
> 0001011B002F
> -rw--- 1 postgres postgres 16777216 Oct 26 07:58
> 0001011B0030
> -rw--- 1 postgres postgres 16777216 Oct 26 07:55
> 0001011B0031
> -rw--- 1 postgres postgres 16777216 Oct 26 07:56
> 0001011B0032
> -rw--- 1 postgres postgres 16777216 Oct 26 07:59
> 0001011B0033
> -rw--- 1 postgres postgres 16777216 Oct 26 08:05
> 0001011B0034
> -rw--- 1 postgres postgres 16777216 Oct 26 08:04
> 0001011B0035
> -rw--- 1 postgres postgres 16777216 Oct 26 08:02
> 0001011B0036
> -rw--- 1 postgres postgres 16777216 Oct 26 08:03
> 0001011B0037
> -rw--- 1 postgres postgres 16777216 Oct 26 08:00
> 0001011B0038
> -rw--- 1 postgres postgres 16777216 Oct 26 08:01
> 0001011B0039
> -rw--- 1 postgres postgres 16777216 Oct 26 08:06
> 0001011B003A
> -rw--- 1 postgres postgres 16777216 Oct 26 08:07
> 0001011B003B
> -rw--- 1 postgres postgres 16777216 Oct 26 08:09
> 0001011B003C
> -rw--- 1 postgres postgres 16777216 Oct 26 08:08
> 0001011B003D
>
>
> Conteúdo da archive_status:
>
> -rw--- 1 postgres postgres 0 Oct 25 21:23
> 00010117005C.0028.backup.done
> -rw--- 1 postgres postgres 0 Oct 26 08:25 0001011A00CB.done
> -rw--- 1 postgres postgres 0 Oct 26 08:26 0001011A00CC.done
> -rw--- 1 postgres postgres 0 Oct 26 08:27 0001011A00CD.done
> -rw--- 1 postgres postgres 0 Oct 26 08:28 0001011A00CE.done
> -rw--- 1 postgres postgres 0 Oct 26 08:29 0001011A00CF.done
> -rw--- 1 postgres postgres 0 Oct 26 08:30 0001011A00D0.done
> -rw--- 1 postgres postgres 0 Oct 26 08:31 0001011A00D1.done
> -rw--- 1 postgres postgres 0 Oct 26 08:32 0001011A00D2.done
> -rw--- 1 postgres postgres 0 Oct 26 08:33 0001011A00D3.done
> -rw--- 1 postgres postgres 0 Oct 26 08:34 0001011A00D4.done
> -rw--- 1 postgres postgres 0 Oct 26 08:35 0001011A00D5.done
> -rw--- 1 postgres postgres 0 Oct 26 08:36 0001011A00D6.done
> -rw--- 1 postgres postgres 0 Oct 26 08:37 0001011A00D7.done
> -rw--- 1 postgres postgres 0 Oct 26 08:38 0001011A00D8.done
> -rw--- 1 postgres postgres 0 Oct 26 08:39 0001011A00D9.done
> -rw--- 1 postgres postgres 0 Oct 26 08:40 0001011A00DA.done
> -rw--- 1 postgres postgres 0 Oct 26 08:41 0001011A00DB.done
> -rw--- 1 postgres postgres 0 Oct 26 08:42 0001011A00DC.done
> -rw--- 1 postgres postgres 0 Oct 26 08:43 0001011A00DD.done
> -rw--- 1 postgres postgres 0 Oct 26 08:44 0001011A00DE.done
> -rw--- 1 postgres postgres 0 Oct 26 08:45 0001011A00DF.done
> -rw--- 1 postgres postgres 0 Oct 26 08:46 0001011A00E0.done
> -rw--- 1 postgres postgres 0 Oct 26 08:47 0001011A00E1.done
> -rw--- 1 postgres postgres 0 Oct 26 08:48 0001011A00E2.done
> -rw--- 1 postgres postgres 0 Oct 26 08:49 0001011A00E3.done
> -rw--- 1 postgres postgres 0 Oct 26 08:50 0001011A00E4.done
> -rw--- 1 postgres postgres 0

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

2016-10-26 Por tôpico Cleiton Luiz Domazak 
2016-10-26 9:13 GMT-02:00 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 :
>>
>>>
>>>
>>> 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?
>

É uma única tabela de teste, num cluster criado só pra isso, justamente
para isolar totalmente.

>
>
>>
>>
>> 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;
>
>
>
"teste";"1200 MB"
"pg_depend";"872 kB"
"pg_proc";"832 kB"
"pg_attribute";"592 kB"
"pg_rewrite";"480 kB"
"pg_description";"400 kB"
"pg_statistic";"352 kB"
"pg_collation";"320 kB"
"pg_operator";"192 kB"
"pg_type";"168 kB"
"pg_class";"160 kB"
"pg_amop";"128 kB"
"pg_constraint";"80 kB"
"pg_amproc";"72 kB"
"pg_conversion";"72 kB"
"sql_features";"64 kB"
"pg_index";"56 kB"
"pg_opclass";"56 kB"
"pg_cast";"48 kB"
"pg_opfamily";"48 kB"
"pg_ts_config_map";"48 kB"
"pg_shdepend";"40 kB"
"pg_ts_template";"40 kB"
"pg_ts_dict";"40 kB"
"pg_tablespace";"40 kB"
"pg_ts_parser";"40 kB"
"pg_authid";"40 kB"
"pg_extension";"40 kB"
"pg_am";"40 kB"
"pg_database";"40 kB"
"pg_namespace";"40 kB"
"pg_ts_config";"40 kB"
"pg_language";"40 kB"
"pg_aggregate";"32 kB"
"pg_shdescription";"32 kB"
"pg_trigger";"32 kB"
"pg_pltemplate";"24 kB"
"pg_enum";"24 kB"
"pg_range";"24 kB"
"pg_attrdef";"24 kB"
"pg_inherits";"16 kB"
"sql_languages";"16 kB"
"pg_seclabel";"16 kB"
"pg_db_role_setting";"16 kB"
"pg_default_acl";"16 kB"
"sql_sizing";"16 kB"
"sql_packages";"16 kB"
"pg_event_trigger";"16 kB"
"pg_auth_members";"16 kB"
"pg_foreign_data_wrapper";"16 kB"
"sql_implementation_info";"16 kB"
"sql_parts";"16 kB"
"pg_user_mapping";"16 kB"
"pg_foreign_server";"16 kB"
"pg_shseclabel";"8192 bytes"
"pg_largeobject";"8192 bytes"
"sql_sizing_profiles";"8192 bytes"
"pg_largeobject_metadata";"8192 bytes"
"pg_foreign_table";"8192 bytes"




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

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

2016-10-26 Por tôpico 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 :
>
>>
>>
>> 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

[pgbr-geral] Archive não processado

2016-10-26 Por tôpico Cleiton Luiz Domazak 
Bom dia.

Ativei o archive e estou utilizando o Wal-e, porém hoje percebi em um dos
servidores de teste que um range inteiro de Wal files não foram
processados, eles estão na pg_xlog, e não foram processados pelo
archive_command e nem estão na archive_status.

Alguém tem alguma idéia do pq?

O ambiente é "PostgreSQL 9.4.9 x64 em CentOS 7 x64"

postgresql.conf

checkpoint_segments = 64
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
wal_keep_segments = 30
max_wal_senders = 3
wal_level = hot_standby
archive_mode = on
archive_command = 'envdir /etc/wal-e.d/env wal-e wal-push %p'
archive_timeout = 60

Uma parte dos arquivos gerados, o e-mail foi escrito 26/10/16 - 08:58:

-rw--- 1 postgres postgres 16777216 Oct 26 07:45
0001011B0027
-rw--- 1 postgres postgres 16777216 Oct 26 07:44
0001011B0028
-rw--- 1 postgres postgres 16777216 Oct 26 07:46
0001011B0029
-rw--- 1 postgres postgres 16777216 Oct 26 07:50
0001011B002A
-rw--- 1 postgres postgres 16777216 Oct 26 07:51
0001011B002B
-rw--- 1 postgres postgres 16777216 Oct 26 07:52
0001011B002C
-rw--- 1 postgres postgres 16777216 Oct 26 07:53
0001011B002D
-rw--- 1 postgres postgres 16777216 Oct 26 07:57
0001011B002E
-rw--- 1 postgres postgres 16777216 Oct 26 07:54
0001011B002F
-rw--- 1 postgres postgres 16777216 Oct 26 07:58
0001011B0030
-rw--- 1 postgres postgres 16777216 Oct 26 07:55
0001011B0031
-rw--- 1 postgres postgres 16777216 Oct 26 07:56
0001011B0032
-rw--- 1 postgres postgres 16777216 Oct 26 07:59
0001011B0033
-rw--- 1 postgres postgres 16777216 Oct 26 08:05
0001011B0034
-rw--- 1 postgres postgres 16777216 Oct 26 08:04
0001011B0035
-rw--- 1 postgres postgres 16777216 Oct 26 08:02
0001011B0036
-rw--- 1 postgres postgres 16777216 Oct 26 08:03
0001011B0037
-rw--- 1 postgres postgres 16777216 Oct 26 08:00
0001011B0038
-rw--- 1 postgres postgres 16777216 Oct 26 08:01
0001011B0039
-rw--- 1 postgres postgres 16777216 Oct 26 08:06
0001011B003A
-rw--- 1 postgres postgres 16777216 Oct 26 08:07
0001011B003B
-rw--- 1 postgres postgres 16777216 Oct 26 08:09
0001011B003C
-rw--- 1 postgres postgres 16777216 Oct 26 08:08
0001011B003D


Conteúdo da archive_status:

-rw--- 1 postgres postgres 0 Oct 25 21:23
00010117005C.0028.backup.done
-rw--- 1 postgres postgres 0 Oct 26 08:25 0001011A00CB.done
-rw--- 1 postgres postgres 0 Oct 26 08:26 0001011A00CC.done
-rw--- 1 postgres postgres 0 Oct 26 08:27 0001011A00CD.done
-rw--- 1 postgres postgres 0 Oct 26 08:28 0001011A00CE.done
-rw--- 1 postgres postgres 0 Oct 26 08:29 0001011A00CF.done
-rw--- 1 postgres postgres 0 Oct 26 08:30 0001011A00D0.done
-rw--- 1 postgres postgres 0 Oct 26 08:31 0001011A00D1.done
-rw--- 1 postgres postgres 0 Oct 26 08:32 0001011A00D2.done
-rw--- 1 postgres postgres 0 Oct 26 08:33 0001011A00D3.done
-rw--- 1 postgres postgres 0 Oct 26 08:34 0001011A00D4.done
-rw--- 1 postgres postgres 0 Oct 26 08:35 0001011A00D5.done
-rw--- 1 postgres postgres 0 Oct 26 08:36 0001011A00D6.done
-rw--- 1 postgres postgres 0 Oct 26 08:37 0001011A00D7.done
-rw--- 1 postgres postgres 0 Oct 26 08:38 0001011A00D8.done
-rw--- 1 postgres postgres 0 Oct 26 08:39 0001011A00D9.done
-rw--- 1 postgres postgres 0 Oct 26 08:40 0001011A00DA.done
-rw--- 1 postgres postgres 0 Oct 26 08:41 0001011A00DB.done
-rw--- 1 postgres postgres 0 Oct 26 08:42 0001011A00DC.done
-rw--- 1 postgres postgres 0 Oct 26 08:43 0001011A00DD.done
-rw--- 1 postgres postgres 0 Oct 26 08:44 0001011A00DE.done
-rw--- 1 postgres postgres 0 Oct 26 08:45 0001011A00DF.done
-rw--- 1 postgres postgres 0 Oct 26 08:46 0001011A00E0.done
-rw--- 1 postgres postgres 0 Oct 26 08:47 0001011A00E1.done
-rw--- 1 postgres postgres 0 Oct 26 08:48 0001011A00E2.done
-rw--- 1 postgres postgres 0 Oct 26 08:49 0001011A00E3.done
-rw--- 1 postgres postgres 0 Oct 26 08:50 0001011A00E4.done
-rw--- 1 postgres postgres 0 Oct 26 08:51 0001011A00E5.done
-rw--- 1 postgres postgres 0 Oct 26 08:52 0001011A00E6.done
-rw--- 1 postgres postgres 0 Oct 26 08:53 0001011A00E7.done
-rw--- 1 postgres postgres 0 Oct 26 08:54 0001011A00E8.done
-rw--- 1 postgres postgres 0 Oct 26 08:55 0001011A00E9.done
-rw---