Prezados colegas,
É amanhã o PgDay Curitiba na Celepar. Se você ainda não se inscreveu, ainda
da tempo.
Data: *03 de Março de 2016 das 8h30 às 17h*.
Local: *CELEPAR* - Tecnologia da Informação e Comunicação do Paraná
Sala:
*Auditório Jarbas Pessoa de Oliveira*
Programação disponível no site.
Acho que a consulta abaixo pode te ajudar:
SELECT esquema, tabela,
pg_size_pretty(pg_relation_size(esq_tab)) AS tamanho,
pg_size_pretty(pg_total_relation_size(esq_tab)) AS tamanho_total
FROM (SELECT '\"' ||tablename|| '\"' AS tabela,
schemaname AS esquema,
Boa tarde Pessoal,
Estou tentando saber se uma base criada foi executa o restore ou não.
Praticamente é saber se ela tem alguma tabela (estrutura) criado.
Tentei verficar pelo tamanho pelos sequintes comandos:
select pg_size_pretty(pg_database_size('NomeBase'));
SELECT
On 02-03-2016 17:24, Fabrízio de Royes Mello wrote:
>
> [...corte...]
>
> Porque no final ele tem o ".54" que indica o segmento de 1GB que está
> sendo criado.
>
Um detalhe, não verifiquei se essa informação acima é verdadeira... vou
dar uma olhada e em seguida confirmo 100%.
> Veja nos logs
On 02-03-2016 17:24, Fabrízio de Royes Mello wrote:
> Pelo nome do temp file "pgsql_tmp7263.54" parece ser a reconstrução de
> um data file (por ALTER TABLE, REINDEX, CREATE INDEX, VACUUM FULL, etc).
> Porque no final ele tem o ".54" que indica o segmento de 1GB que está
> sendo criado.
>
O 54 é
Neste exato momento, estamos mudando de delphi7 para XE5 e junto utilizando
FireDac, tudo isto em cima do PostgreSQL-8.2. Optamos por adequar o sistema
primeiro, até porque, pegaríamos a versão mais estável do FireDac que nos
dá um acesso nativo ao banco com performance superior a outros tipos de
On 01-03-2016 11:30, Luiz Henrique wrote:
> Pessoal,
>
> Temos uma aplicação JBOSS que frequentemente apresenta a mensagem de log
> conforme abaixo. As vezes causa lentidão no uso da aplicação. Desconfio
> que o parâmetro maintenance_work_mem esteja "tímido", muito pequeno.
> Gostaria da sugestão
Olá,
Estou querendo fazer um dump do mínimo necessário (para ambiente de testes).
Seria interessante ter as últimas 1000 rows por exemplo das tabelas.
Então estava pensando em algo:
> pg_dump dbname --schema-only -f db_schema.sql
CREATE OR REPLACE FUNCTION _save_top_1000_row_tables(chemin
2016-03-02 8:11 GMT-04:00 Andre Cavalcante :
> Olá,
>
> 2016-03-01 21:21 GMT-04:00 Leandro Guimarães Faria Corcete DUTRA <
> l...@dutras.org>:
>
>> Le 1 mars 2016 17:17:02 GMT-03:00, Andre Cavalcante <
>> andre.d.cavalca...@gmail.com> a écrit :
>> >
>> >id serial
>>
2016-03-02 9:13 GMT-03:00 Andre Cavalcante :
> Aprendiz
> ---
> id serial
> matricula varchar
> nome varchar
Cada um é uma chave? Ou a chave são os dois atributos?
> ItemHistorico
> --
> id serial {PK - cada item tem um número que o
Olá
ontem tivemos duas paradas na replicação do primário para o standby, ou
seja, o standby não recebeu mais atualizações do primário.
Após mais de 4 horas assim, reiniciamos o standby e tudo voltou ao normal.
Você faz consultas sobre o standby? Você faz dump sobre o standby?
Não existem
On 02-03-2016 11:22, Everton Berz wrote:
> ontem tivemos duas paradas na replicação do primário para o standby, ou
> seja, o standby não recebeu mais atualizações do primário.
> Após mais de 4 horas assim, reiniciamos o standby e tudo voltou ao normal.
>
O que você quis dizer com parou de
Olá
ontem tivemos duas paradas na replicação do primário para o standby, ou
seja, o standby não recebeu mais atualizações do primário.
Após mais de 4 horas assim, reiniciamos o standby e tudo voltou ao normal.
Não existem mensagens de erro no log do PostgreSQL primário nem no standby.
Nem o
Bom dia, pessoal. Tenho uma tabela assim:
id_hor descricao_hor
1 07:30
2 08:20
3 09:10
4 10:15
5 11:05
6 11:55
Tablela Agenda - Relacionada
14 matches
Mail list logo