> Infelizmente acabou de parar o postgres novamente,,, única coisa que consta
> no log desde hoje de madrugada é isso:
>
>
>
> 2016-04-13 14:02:14 BRT WARNING: worker took too long to start; canceled
> 2016-04-13 14:03:19 BRT WARNING: worker took too long to start; canceled
> 2016-04-13 14:04:21
Apenas para registrar o fato, também estamos com esse problema, em
menor escala mas vem acontecendo...
São máquinas com Windows 10 64bits, com PostgreSQL 9.2.3, em 2
máquinas que apresentam essa situação, diferente do amigo, não possuem
instalados qualquer aplicativo de banco (GBuster, etc). Nesse
> Preciso configurar a instalação silenciosa do PostgreSQL 9.3, já
> habilitando o Apache.
> Alguém pode dar uma dica do comando?
Windows: postgresql-9.x.x.x-windows-xyy.exe --unattendedmodeui minimal
--mode unattended --superaccount useracc --serviceaccount useracc
--servicepassword passwd --su
Obrigado pelas respostas...
> Você tem log de erros na aplicação?
Tenho log sim, os componentes (Delphi) me retornam essa mensagem:
Error on data writing to the connection:
Foi forçado o cancelamento de uma conexão existente pelo host remoto.
Socket Error Code: 10054($2746).
> Sim pode ser um fi
Pessoal, estou com uma situação que não consigo identificar a origem
do problema.
O cliente reclama que o sistema perde conexão com o banco de dados sem
motivo aparente, não é possível simular o problema (nem eu nem ele
conseguimos reproduzir no momento que queremos), acontece muitas vezes
em inte
> Douglas, analise todo o processo e tente reduzir a quantidade de requisições
> que a aplicação faz ao banco de dados, com isso você conseguirá reduzir o
> tempo total do processo.
Não sei se é o caso, mas ele falou em ERP, nesse caso duvido que tenha
um ponto apenas que precisara ser melhorado..
> Essa é uma limitação conhecida (até a 9.2). A partir do 9.3, isso foi
> resolvido com uma nova sintaxe que bloqueia transações se, e somente se, a
> chave for alterada (colunas que não participam da FK não mais bloqueiam
> transações -- como é o seu caso). Portanto, atualize para versão 9.3 ou
>
> Não é a trigger que causa nada, é um lock normal. Você fez um update na
> primeira transação, isso bloqueia a linha para outras alterações. O bloqueio
> só é liberado no commit. Isso é parte do que chamamos de ACID - a primeira
> letra, atomicidade, uma operação é válida no momento de sua confirm
Pessoal, preciso de ajuda para entender o motivo de uma trigger
bloquear um select (update em outra tabela com sub select).
Vejam o exemplo:
Minhas duas tabelas:
create table tb_produtoestoque (
id integer not null,
produto_id integer not null,
qt_estoque numeric(18,4) not null);
alter table
Pessoal, estou com uma tabela que aparentemente está com um Lock mas
não consigo encontrar quem fez isso.
Em virtude do lock a tabela está indisponível, não responde mais a
selects, inserts, deletes ou updates.
O que posso fazer para voltar essa tabela?
Como identificar que transação travou ela (i
Pessoal, tenho um servidor com as configurações abaixo.
Servidor (VIRTUALIZADO):
- SO Linux (OpenSuse 12.2 – 64bits)
- Processador 8 núcleos
- Memória 60GB
- Storage (não lembro especificações)
- Dedicado
PostgreSQL
- 9.2 64bits compilado
- Database com 290GB
- 200 conexões
- Replica
Preciso novamente da ajuda de vocês!
Possuo um ambiente com PostgreSQL 9.2 (PostgreSQL 9.2.3 on
x86_64-unknown-linux-gnu, compiled by gcc (SUSE Linux) 4.7.1 20120723
[gcc-4_7-branch revision 189773], 64-bit) e OpenSuse 12.2 com
replicação nativa configurada.
Fiz um backup da base no servidor
> Espero ter ajudado..
Vlw galera obrigado pela ajuda...
Tanto restore_command quanto wal_keep_segments funcionam
perfeitamente cada um com suas vantagens
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.o
>> Certo Euler, mas neste caso eu teria que abandonar a replicação por
>> Streaming?
>>
> Não.
A ideia então é que quando a replicação por Streaming perder a
sincronização, ela se recupere através dos arquivos de WAL previamente
arquivados?
Bastaria então que eu ajustasse no srv Slave:
[recovery.
> Para não ter esse problema o ideal é arquivar os logs de transação por
> pelo menos 1 dia e definir restore_command no recovery.conf. Assim, você
> nunca precisará refazer o servidor réplica ou ser pego de surpresa
> porque um REINDEX ou VACUUM consumiu todo wal_keep_segments definido
> previamen
Amigos, estou com um problema em uma replicação PostgreSQL 9.2.3
(OpenSuse 12.2) usando Streaming Replication. O problema ocorre ao
executar uma rotina de vacuum (de forma manual) e os servidores perdem
o sincronismo.
Log do srv Slave:
2013-12-08 04:14:39 BRST [10615]: [2-1] user=,db= FATAL: coul
>
> Então, parece que a única solução é coletando os dados mesmo, de tempo em
> tempo, e salvando num local a parte.
> De qualquer forma, como você disse usa o Zabbix, não basta fazer isso por
> ele? Configure-o para coletar essas informações, em seguida é só filtrar os
> períodos.
>
Então Matheu
Obrigado pelas respostas!
Outra técnica é reiniciando as estatísticas:
>
> SELECT pg_stat_reset();
Preciso esclarecer outro detalhe, estou coletando as informações e
utilizando no Zabbix, não posso zerar as estatísticas.
te aconselho usar outras ferramentas para auxiliar como o PGObserver[1] ou
Amigos, estou precisando recuperar uma informação do PostgreSQL:
- Percentual de inserts que ocorreram entre dois períodos (T1, T2) em um
determinado database.
Existe a view pg_stat_database que possui informações sobre o volume de
inserts, updates, deletes que ocorreram em um database (select tup
Desculpe pessoal mas não estou mais recebendo os e-mails da lista, o último
que recebi foi no dia 08/06/2013, vou tentar consertar isso...
Quanto as informações, obrigado pelas respostas, apenas uma dúvida:
Considerando utilizar o pg_basebackup no servidor Slave, eu não consigo
realizar backups in
Olá pessoal, estou tendo dificuldades em configurar um servidor Slave para
fazer backup incremental (PITR).
Para replicação utilizo a nativa do PostgreSQL (Streaming Replication).
A versão do PostgreSQL 9.2.3 compilada: PostgreSQL 9.2.3 on
x86_64-unknown-linux-gnu, compiled by gcc (SUSE Linux) 4
Legal Fabrízio! Realmente temos um ambiente parecido.
Aplicação legada, +1050 tabelas, +1050 functions, +500 triggers É
difícil refatorar uma aplicação grande e legada em pouco tempo, sem contar
os valores financeiros investidos em tantas horas de refatoração...
Praticamente elencamos os mesm
E ai pessoal, beleza?
Nos últimos dias estive empenhado realizando a migração de nossas
aplicações que utilizavam o PostgreSQL 8.2.x para a versão recente 9.2.x.
Upgrade bem grande...
Bom, tive vários problemas, mas praticamente todos relacionados a cast ou
com operadores (varchar = numeric) (num
Nenhuma mensagem de kill é logado em /var/log/messages
Na minha ignorância pergunto!
Digamos que o Killer esta matando o processo, porque ele mataria apenas as
conexões do postgresql e não mata o processo principal (postmaster) do
PostgreSQL? Se ele estaria matando o postmaster eu teria que subir
>>* *Detalhes:**>>* *>>* 1. O problema acontece apenas se os dois SGBDs
>>estiverem realizando tarefas*>>* pesadas, se apenas um estiver rodando
>>uma tarefa complexa não ocorre o*>>* problema;*>>* 2. Aparentemente o
>>servidor esta ok, não existe uma sobrecarga (discos,*>>* memori
Então, não deveria mesmo existir, mas deve ter ficado outros arquivos
“presos” fazendo com o Postgres ficasse em “meio termo”.
A versão do Postgres que utilizamos é a 8.2.4 e neste caso o SO é OpenSuse
11.3(64)
Existe uma rotina de backup que o cliente agendou para as 01h, ela da um
stop no banco,
Pessoal, peço auxilio com um problema que tive.
Hoje um servidor com banco Postgres parou e não subia mais, a mensagem que
dava ao tentar iniciar era “pg_ctl: PID file
"/usr/local/pgsql/data/postmaster.pid" does not exist Server running?”.
Procurando em alguns logs do banco, identifiquei que em
Galera, preciso de um help de vcs.
A empresa que trabalho oferece atualmente ao cliente duas opções para banco
de dados, Postgres e Firebird.
Internamente trabalhamos desenvolvendo procedures/triggers etc
(praticamente 80% das regras de negocio se concentram no Banco de Dados) em
Firebird e uma f
28 matches
Mail list logo
