Dá uma olhada nos logs deve te dizer mais coisa lá
É o master ou o slave este servidor? Você pode usar o pg_isready [1] pra
ver o estado do servidor também.
[1] https://www.postgresql.org/docs/9.5/static/app-pg-isready.html
Lucas
2018-03-07 11:59 GMT+13:00 Fábio Uberti
Wislan, você já deu uma olhada no pg_upgrade?
Já fiz um processo de uma base de mais de 200 G usando ele. Para mim é o
modo mais rápido hoje existente.
Dá uma olhada na feature "link" dele.
Em 11 de jan de 2018 14:44, "Wislan Lopes" escreveu:
Bruno, bom dia!
Quando
Bruno, bom dia!
Quando coloquei pra rodar o script gerou um erro solicitando que fosse
acrescentado o parâmetro: --no-synchronized-snapshots no comando pg_dump
Após acrescentar começou a rodar e realmente é bem rápido, porém quando
chegou em uma base de dados que possui documentos binários(pdfs,
Deu certo?
Em qua, 10 de jan de 2018 às 09:03, Wislan Lopes
escreveu:
> Bruno, desde já muito obrigado pelo retorno e ajuda. Estarei testando o
> script e retorno informando como foi o processo.
>
> Valew mesmo.
>
> Em 9 de janeiro de 2018 22:54, Bruno Silva
Bruno, desde já muito obrigado pelo retorno e ajuda. Estarei testando o
script e retorno informando como foi o processo.
Valew mesmo.
Em 9 de janeiro de 2018 22:54, Bruno Silva escreveu:
> Wislan, a diferença das versões pode ter características que gerem
> problemas.
Corrigindo o trecho "a diferença das versões pode ter características que
gerem problema"
A diferença entre as versões ( 9.x <> 9.y) pode fazer com que o script
gerado pelo pg_dump de versões distintas acabe gerando um arquivo/script de
dump incompatível com a versão de destino.
Em ter, 9 de jan
Wislan, a diferença das versões pode ter características que gerem
problemas. Prefira sempre usar o pg_dump na versão que você deseja migrar.
Outra coisa, eu prefiro fazer o dump por bases, fica mais fácil de
trabalhar e até pra restaurar uma só base - caso seja necessário.
E ainda pode fazer o
Em 9 de janeiro de 2018 15:05, Bruno Silva escreveu:
> Como está sendo feito o Export (sintaxe do comando)?
>
>> Bruno estou utilizando o comando sem parâmetros: pg_dumpall -Uusuario
> -hIP > dump.sql
Se está fazendo para o 9.5 por que não usa o pg_dumpall da versão 9.5
Como está sendo feito o Export (sintaxe do comando)?
Se está fazendo para o 9.5 por que não usa o pg_dumpall da versão 9.5 ?
E como está sendo feito o import?
Em ter, 9 de jan de 2018 às 14:56, Wislan Lopes
escreveu:
> Prezados, boa tarde!
>
> Estou realizando uma
2017-01-03 16:30 GMT-02:00 Flaudísio Tolentino :
>
> Legal, cara! Espero que tenha sucesso no seu trabalho e admiro sua
> pré-disposição em contribuir de volta, especialmente com algo validado por
> toda a metodologia requerida para um trabalho acadêmico - o que
>
>
> ESSA é a ideia, assim que constatar na prática os efeitos da
> modificação proposta no artigo, pretendo implementar na ultima versão.
>
Legal, cara! Espero que tenha sucesso no seu trabalho e admiro sua
pré-disposição em contribuir de volta, especialmente com algo validado por
toda a
2017-01-03 15:53 GMT-02:00 Neto pr :
> Pretendo verificar se as modificações realizadas desde a versão 9.0.1
> até a atual, modificaram muito o modelo de custos do postgresql, pois
> o Patch que estou aplicando, modifica funções de custos, para que
> estimativas sejam mais
Em 3 de janeiro de 2017 13:21, Euler Taveira escreveu:
> On 02-01-2017 14:10, Guimarães Faria Corcete DUTRA, Leandro wrote:
>> Pergunto-me qual a validade de experimentar questoes de desempenho
>> numa versao tao obsoleta, sendo que quase todas as versoes do
>> PostgreSQL
2017-01-03 15:46 GMT-02:00 Neto pr :
>
> perdão, mas o seria OP ?
/Original poster/, literalmente ‘publicador original’. No caso,
consulente original, ou seja, quem começou a discussao.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191
Em 2 de janeiro de 2017 23:33, Tiago José Adami escreveu:
>> Pergunto-me qual a validade de experimentar questoes de desempenho
>> numa versao tao obsoleta, sendo que quase todas as versoes do
>> PostgreSQL trazem bons avanços. Creio que seria mais relevante
>> aplicar isso aa
2017-01-03 13:21 GMT-02:00 Euler Taveira :
> On 02-01-2017 14:10, Guimarães Faria Corcete DUTRA, Leandro wrote:
>> Pergunto-me qual a validade de experimentar questoes de desempenho
>> numa versao tao obsoleta, sendo que quase todas as versoes do
>> PostgreSQL trazem bons
On 02-01-2017 14:10, Guimarães Faria Corcete DUTRA, Leandro wrote:
> Pergunto-me qual a validade de experimentar questoes de desempenho
> numa versao tao obsoleta, sendo que quase todas as versoes do
> PostgreSQL trazem bons avanços. Creio que seria mais relevante
> aplicar isso aa v. 10.
>
A
> Pergunto-me qual a validade de experimentar questoes de desempenho
> numa versao tao obsoleta, sendo que quase todas as versoes do
> PostgreSQL trazem bons avanços. Creio que seria mais relevante
> aplicar isso aa v. 10.
Resposta off-topic já que o OP conseguiu resolver seu problema: no
meio
2017-01-01 3:20 GMT-02:00 Neto pr :
> Guimaraes, sobre patch, ele implementa o que esta descrito neste paper:
>
> http://dl.acm.org/citation.cfm?id=2236588
Ou seja, altera o otimizador para saber mais a respeito do
armazenamento em memória nao-volátil, certo?
> Estou
Pessoal
A principio resolvi o problema. Obrigado pelas dicas...
Segue a solucao caso alguem tenha este problema.
Para compilar os fontes do Postgresql 9.0.1 utilizando GCC-4.9 eu
utilizei a seguinte diretiva (
./configure -prefix=/opt/postgres9.0 CFLAGS="-Wno-aggressive-loop-optimizations"
Guimaraes, sobre patch, ele implementa o que esta descrito neste paper:
http://dl.acm.org/citation.cfm?id=2236588
Estou desenvolvendo uma pesquisa,no qual sera necessario que o
Postgresql tenha essas caracteristicas, que o patch prove,
modificando o codigo fonte original. Nao posso migrar
2016-12-31 21:58 GMT-02:00 Neto pr :
> Eu preciso dessa versão 9.0.1, pois um pesquisador da alemanha me
> enviou, para ajudar na minha pesquisa de Pós-graduação.
Te enviou o quê exatamente?
> O patch altera
> o postgreSQL para diferenciar características entre HDD e SSD. É
Pessoal
Eu preciso dessa versão 9.0.1, pois um pesquisador da alemanha me
enviou, para ajudar na minha pesquisa de Pós-graduação. O patch altera
o postgreSQL para diferenciar características entre HDD e SSD. É para
fins de pesquisa que estou utilizando.
Ao compilar, da tudo certo, mas ao fazer
2016-12-31 19:54 GMT-02:00 Neto pr :
>
> Acho que a dúvida é mais relacionada ao S.O. Linux no entanto o
> Posgresql é parte do problema que estou enfrentando.
Acho que terás mais ajuda na lista do SO. Detalhe, Linux é só o
núcleo; tua dúvida é de uma distribuição GNU/Linux.
On 31/12/2016 19:54, Neto pr wrote:
Ola pessoal
Acho que a dúvida é mais relacionada ao S.O. Linux no entanto o
Posgresql é parte do problema que estou enfrentando.
Tenho que compilar o SGBD Postgresql 9.0.1 que tem um Patch para esta
versão e infelizmente a compilação só funciona no gcc-4.7,
Pq nao tenta um backup/restore provavelmente corrompeu
Em 15/10/2016 07:55, "Antonio Silva" escreveu:
> Olá,
>
> Continuei a ler sobre o tema e usei o comando pg_lsclusters
>
> $ pg_lsclusters
> Ver Cluster Port Status OwnerData directory Log file
> 9.5
Obrigado Matheus, realmente a chave do problema estava no arquivo de log.
Abraços
Antônio
Em 16 de outubro de 2016 02:10, Matheus de Oliveira <
matioli.math...@gmail.com> escreveu:
>
> 2016-10-15 7:54 GMT-03:00 Antonio Silva :
>
>> Ver Cluster Port Status OwnerData
Caros,
Com uma orientação da lista internacional eu consegui resolver o problema.
Deixo registrado aqui o que houve.
O arquivo de log em /var/log/postgresql/postgresql-9.5-main.log indicou:
2016-10-15 06:15:20 BRT [995-1] FATAL: data directory
"/var/lib/postgresql/9.5/main" has group or world
2016-10-15 7:54 GMT-03:00 Antonio Silva :
> Ver Cluster Port Status OwnerData directory Log file
> 9.5 main5432 down postgres /var/lib/postgresql/9.5/main
> /var/log/postgresql/postgresql-9.5-main.log
>
O banco sobe depois de executar o comando que
Olá,
Continuei a ler sobre o tema e usei o comando pg_lsclusters
$ pg_lsclusters
Ver Cluster Port Status OwnerData directory Log file
9.5 main5432 down postgres /var/lib/postgresql/9.5/main
/var/log/postgresql/postgresql-9.5-main.log
Talvez ajude em um diagnóstico, mas
On Fri, Sep 30, 2016 at 2:28 PM, wrote:
> ERROR: permission denied for schema transporte LINE 1: SELECT 1 FROM ONLY
> "transporte"."anexo_movimento_veiculo" x ...^
> QUERY: SELECT 1 FROM ONLY "transporte"."anexo_movimento_veiculo" x WHERE
> $1
On 29/04/2016 05:09, Lucas Viecelli wrote:
> 2016-04-28 16:12:56 BRT LOG: n?o p?de abrir arquivo
> "pg_xlog/00010247002A" (arquivo de log 583, segmento
> 42): Arquivo ou diret?rio n?o encontrado
>
>
> Se você está utilizando uma versão superior ou igual a 9.4, sugiro
>
> 2016-04-28 16:12:56 BRT LOG: n?o p?de abrir arquivo
> "pg_xlog/00010247002A" (arquivo de log 583, segmento 42):
> Arquivo ou diret?rio n?o encontrado
>
>
Se você está utilizando uma versão superior ou igual a 9.4, sugiro você
utilizar slots, e mesmo assim fazer o arquivamento dos
On 28-04-2016 16:17, Marcell Ribeiro wrote:
> Executo o pg_start_backup, depois o seguinte rsync enviando dados da
> produção pra replicação:
>
> rsync -av --exclude postmaster.pid --exclude postgresql.conf --exclude
> pg_hba.conf --exclude backup_label --exclude 'pg_xlog' --exclude
> 'pg_log'
Opa Fabricio,
Obrigado pela resposta! :)
Realmente, acho que matei uma mosca com uma bazuca, o SET CONSTRAINTS deve
ser o suficiente.
Explicando a situação: é uma operação de atualização de BD, onde preciso
garantir que todas as alterações (scripts) entrem ou sejam revertidas em
caso de erro.
On 15-03-2016 12:52, Murilo Habermann Torquato wrote:
> Fala pessoal,
>
> Para atualizar um banco de dados em produção (usando uma transação)
> precisamos alterar todas as constraints do banco de dados de "DEFERRABLE
> INITIALLY DEFERRED" para "DEFERRABLE INITIALLY IMMEDIATE".
>
> Para isso,
On 12-03-2016 23:21, Pablo Farias wrote:
> gerei um backup com o pgAdmin um arquivo com extensão .backup.
> O servidor esta instalado o postgresql 9.5.1
> Acontece que agora de forma alguma consigo restaurar o backup.
>
> O conteudo do erro esta no link
>
Que link? Para manter o histórico da
Em 13 de mar de 2016 12:58, "Edson - Amplosoft Software" <
ed...@openmailbox.org> escreveu:
>
> Qual e o grupo do telegrama?
https://listas.postgresql.org.br/pipermail/pgbr-geral/2015-December/041959.html
At.
___
pgbr-geral mailing list
Em 13 de março de 2016 11:20:05 BRT, Matheus de Oliveira
escreveu:
>2016-03-12 23:24 GMT-03:00 Pablo Farias :
>
>> gerei um backup com o pgAdmin um arquivo com extensão .backup.
>> O servidor esta instalado o postgresql 9.5.1
>> Acontece que
2016-03-12 23:24 GMT-03:00 Pablo Farias :
> gerei um backup com o pgAdmin um arquivo com extensão .backup.
> O servidor esta instalado o postgresql 9.5.1
> Acontece que agora de forma alguma consigo restaurar o backup.
>
> O conteudo do erro esta no link
>
>
Em sex, 12 de fev de 2016 às 19:08, Mauricio Tavares
escreveu:
> Flávo, boa tarde...
>
> Então, eu não fiz a atualização.
> Até pensei em fazer a atualização para a versão 9.1.20. Porém, até neste
> servidor tem uma base de dados de quase 2 Tb.,
> Ou seja, até que ponto posso
Pessoal, bom dia
Estou passando por um problema ao executar o comando "create extension
postgis".
Erro ao executar o create extension:
postgres=# \c gisdb
You are now connected to database "gisdb" as user "postgres".
gisdb=# create extension postgis;
ERROR: could not access file
Flávo, boa tarde...
Então, eu não fiz a atualização.
Até pensei em fazer a atualização para a versão 9.1.20. Porém, até neste
servidor tem uma base de dados de quase 2 Tb.,
Ou seja, até que ponto posso executar o "yum upgrade postgresql*" com total
segurança?
PS: esta base tem backup.
Em 12 de
Consegui resolver o problema.
Estava faltando instalar alguns componentes no Postgresql.
Executei o comando: postgresql-contrib-9.0
E deu certo.
Obrigado.
2016-02-10 1:36 GMT-02:00 Osvaldo Kussama :
> Em 09/02/16, Thiago H. Barreto
Em 09/02/16, Thiago H. Barreto escreveu:
> Boa tarde Galera.
>
> Estou precisando da ajuda de vocês.
> Tive que mudar um servidor que esta com problemas e quando acesso a
> aplicação dá o seguinte erro.. "não pôde acessar arquivo "$libdir/_int":
> Arquivo ou
Em 24 de novembro de 2015 20:03, Tiago José Adami
escreveu:
> Em 24 de novembro de 2015 19:44, Junior Miranda
> escreveu:
> > C:\"Program Files (x86)"\PostgreSQL\9.3\bin\pg_dump -U senha -h
> localhost -s
> > -f C:\"Program Files (x86)"\Teste
>
>
Em 26 de novembro de 2015 11:19, Fábio Telles Rodriguez
escreveu:
> Vale à pena lembrar que o PostgreSQL nasceu no mundo UNIX e neste universo,
> usar nomes de arquivos e diretórios com espaços... é uma péssima ideia.
No "mundo Windows" facilitaria se os empacotadores da
Em 26 de novembro de 2015 15:31, Glauco Torres
escreveu:
>
>
>
>
> Pessoal,
>>
>> Estou tentando efetuar um COPY via psql local de um arquivo, porém recebo
>> a mensagem: "sequência de bytes é inválida para codificação "UTF8": 0x80"
>>
>> Tanto client_encoding e
No dia 26 de novembro de 2015 às 15:47, Danilo Silva <
danilo.dsg.go...@gmail.com> escreveu:
> Em 26 de novembro de 2015 15:31, Glauco Torres
> escreveu:
>
>>
>>
>>
>>
>> Pessoal,
>>>
>>> Estou tentando efetuar um COPY via psql local de um arquivo, porém
>>> recebo a
Em 26 de novembro de 2015 15:55, Glauco Torres
escreveu:
>
>
> No dia 26 de novembro de 2015 às 15:47, Danilo Silva <
> danilo.dsg.go...@gmail.com> escreveu:
>
>> Em 26 de novembro de 2015 15:31, Glauco Torres
>> escreveu:
>>
>>>
>>>
>>>
>>>
>>>
Em 26 de novembro de 2015 16:02, Danilo Silva
escreveu:
> Em 26 de novembro de 2015 15:55, Glauco Torres
> escreveu:
>
>>
>>
>> No dia 26 de novembro de 2015 às 15:47, Danilo Silva <
>> danilo.dsg.go...@gmail.com> escreveu:
>>
>>> Em 26 de
>
>
>
> Está tudo como UTF8:
>>
>> SHOW
>>
>> client_encoding: UTF8
>> SHOW server_encoding: UTF8
>> file -i: text/plain; charset=utf-8
>>
>>
>> Um detalhe, o arquivo foi gerado no ms sqlserver
>
>
>
Cara esse problema acontece porque o encoding dos dados que você está
importando é
>
>
> file -i: text/plain; charset=utf-8
>
>
> Um detalhe, o arquivo foi gerado no ms sqlserver
>>
>>
>>
> Cara esse problema acontece porque o encoding dos dados que você está
> importando é diferente do da sua base.
>
> Mais os três estão com o mesmo enconding, então não sei o que você tentar
https://pt.m.wikipedia.org/wiki/Marca_de_ordem_de_byte
Em quinta-feira, 26 de novembro de 2015, Franklin Anderson de Oliveira
Souza escreveu:
> Ola ! Acho que isso tem a ver com o utf8 com ou sem BOM.
>
> Sabendo que o banco é utf8 e o arquivo tambem. Abra um editor
Em 26 de novembro de 2015 17:12, Franklin Anderson de Oliveira Souza
escreveu:
> Ola ! Acho que isso tem a ver com o utf8 com ou sem BOM.
>
> Sabendo que o banco é utf8 e o arquivo tambem. Abra um editor qualquer copie
> o conteudo e salve em outro arquivo, supondo que o
On Thu, Nov 05, 2015 at 01:13:10PM -0200, Sebastian Webber wrote:
> Em 4 de novembro de 2015 13:47, Dickson S. Guedes
> escreveu:
>
> >
> >
> >
> E aí Guedes, tudo na boa?
Sim tranquilo! Tirando a chuva em excesso :D
>
>
> > 32512 eh o codigo de retorno de um programa
Em 4 de novembro de 2015 13:47, Dickson S. Guedes
escreveu:
>
>
>
E aí Guedes, tudo na boa?
> 32512 eh o codigo de retorno de um programa executado por outro que
> retornou,
> tambem um codigo de retorno.
>
> 32512 = 127 * 256 => 127 << 8
>
Como Você chegou nessa
Em 4 de novembro de 2015 18:39, Sebastian Webber
escreveu:
>
>
> Em 4 de novembro de 2015 15:07, Raphael Coutinho <
> raphael.couti...@dbmax.com.br> escreveu:
>
>>
>>
>> Em 4 de novembro de 2015 13:18, Sebastian Webber
>> escreveu:
>>
>>>
>>>
>>
>>
Em 4 de novembro de 2015 15:07, Raphael Coutinho <
raphael.couti...@dbmax.com.br> escreveu:
>
>
> Em 4 de novembro de 2015 13:18, Sebastian Webber
> escreveu:
>
>>
>>
>
> Não. Nem gerou o arquivo. Permissão Ok.
>
>
Conforme o Dickson sugeriu: dá uma conferida no PATH
Em 4 de novembro de 2015 13:03, Raphael Coutinho <
raphael.couti...@dbmax.com.br> escreveu:
> Boa tarde pessoal!
>
Boa tarde!
> Alguém já passou por isso.
>
> *AVISO: archive_cleanup_command "pg_archivecleanup -d
> /standby_db/archives/ -x .7z %r 2>> cleanup.log": código retornado 32512*
>
>
Em 4 de novembro de 2015 13:18, Sebastian Webber
escreveu:
>
>
> Em 4 de novembro de 2015 13:03, Raphael Coutinho <
> raphael.couti...@dbmax.com.br> escreveu:
>
>> Boa tarde pessoal!
>>
>
> Boa tarde!
>
>
>> Alguém já passou por isso.
>>
>> *AVISO: archive_cleanup_command
Bom dia Ronaldo,
Primeiramente agradeço a atenção. Seguindo tuas colocações, é possivelmente
mesmo que seja antes da coluna datahora_transacao, tem a única coluna que é
texto na tabela, vou tentar remover acentos e outros caracteres. E os
próximos servidores dedicados para PostGresql vai ser
Rudimar, boa noite
Esse esse é comum em SGBDs PostgreSQL instalado em Windows quando você tem
caracteres estranhos em uma coluna da base de dados. É como se um desses
caracteres realizasse uma quebra de linha parecendo que a coluna não tem
informação. Creio que seja uma coluna antes da coluna
Bom dia, realmente com Custom resolveu problema, Obrigado pela atenção
pessoal.
Em 19 de outubro de 2015 17:12, Rudimar escreveu:
> Com formato "Custom" funcionou... grande dica e simples... vou dar uma
> olhada mais a fundo nesse formatos... o Custom deu um arquivo bem
Estou fazendo isso nesse momento. Posto resultado depois... muito
obrigado...
Em 19 de outubro de 2015 15:21, Rafael Fialho
escreveu:
> é utilizei diferente, 9.3 -> 9.4 , será que pode ser isso? mas ai qual
>> procedimento? tenho os 2 bancos rodando em servidores
>
> Fiz remoto o backup, usando o servidor que tem o 9.4 e depois tentei
> restaurar deu mesmo erro...
>
> D:/Program Files/PostgreSQL/9.4/bin\pg_restore.exe --host localhost --port
> 5432 --username "postgres" --dbname "db" --no-password --data-only --table
> vendas --schema public --verbose
Em 19 de outubro de 2015 16:03, Rudimar escreveu:
> sim fiz restauração :
>
> comando:
> D:/Program Files/PostgreSQL/9.4/bin\pg_dump.exe --host 192.168.1.4 --port
> 5432 --username "postgres" --no-password --format tar --verbose --file
> "vendas.backup" --table
On 19-10-2015 15:21, Rafael Fialho wrote:
> é utilizei diferente, 9.3 -> 9.4 , será que pode ser isso? mas ai
> qual procedimento? tenho os 2 bancos rodando em servidores
> diferentes...
>
>
> Sendo ou não, o correto é utilizar a versão de destino, no caso utilizar
> o pg_dump da
Fiz remoto o backup, usando o servidor que tem o 9.4 e depois tentei
restaurar deu mesmo erro...
D:/Program Files/PostgreSQL/9.4/bin\pg_restore.exe --host localhost --port
5432 --username "postgres" --dbname "db" --no-password --data-only --table
vendas --schema public --verbose
sim fiz restauração :
comando:
D:/Program Files/PostgreSQL/9.4/bin\pg_dump.exe --host 192.168.1.4 --port
5432 --username "postgres" --no-password --format tar --verbose --file
"vendas.backup" --table "public.vendas" "db"
pg_dump: lendo esquemas
pg_dump: lendo tabelas definidas pelo usuário
Com formato "Custom" funcionou... grande dica e simples... vou dar uma
olhada mais a fundo nesse formatos... o Custom deu um arquivo bem menor,
parece que ele compacta o arquivo é isso mesmo?... o problema estava no
"tar" mesmo...
preciso rever meus conceitos de dumps e backups...
Rudimar.
>
> Pessoal,
>
> estou com problema ao dar um pg_dump e restaurar pg_restore, exportando do
> 9.3 e importando no 9.4
>
Você realizou o restore com o binário da versão 9.4, mas utilizou o pg_dump
de qual versão?
Para realizar este tipo de migração você deve realizar o dump com o binário
da versão
é utilizei diferente, 9.3 -> 9.4 , será que pode ser isso? mas ai qual
procedimento? tenho os 2 bancos rodando em servidores diferentes...
Em 19 de outubro de 2015 14:59, Rafael Fialho
escreveu:
> Pessoal,
>>
>> estou com problema ao dar um pg_dump e restaurar
>
> é utilizei diferente, 9.3 -> 9.4 , será que pode ser isso? mas ai qual
> procedimento? tenho os 2 bancos rodando em servidores diferentes...
>
Sendo ou não, o correto é utilizar a versão de destino, no caso utilizar o
pg_dump da versão 9.4.
Utilize o pg_dump 9.4 para fazer backup remoto, se
Em 2 de outubro de 2015 15:18, Danilo Silva
escreveu:
> Pessoal,
>
> Tenho um arquivo CSV e ao importá-lo com o comando copy dá o seguinte erro:
> ERRO: sequência de bytes é inválida para codificação "UTF8": 0xa6
> CONTEXTO: COPY baseativa, linha 571427
>
Qual é a
On Thu, Jun 11, 2015 at 11:31 AM, jlroman...@gmail.com wrote:
%t ERROR: column buffers_backend_fsync does not exist at character 8
%t STATEMENT: select buffers_backend_fsync from pg_stat_bgwriter
%t ERROR: column state does not exist at character 14
%t STATEMENT: select count(state) from
On 28-04-2015 08:41, Vilson wrote:
Instalei o postgresql 9.4 no windows 8.1 e funcionou bem. Mas comesou dar a
mensagem 1053 o serviço não respondeu a requisição de controle em tempo
hábil. E não consegui mais funcionar.
Alguém já passou por isso?
Isso não é um problema do postgres e
O WINDOWS É 8.1 64 BITS
From: Vilson
Sent: Tuesday, April 28, 2015 8:41 AM
To: pgbr-geral@listas.postgresql.org.br
Subject: [pgbr-geral] erro 1053 no windows 8.1
Instalei o postgresql 9.4 no windows 8.1 e funcionou bem. Mas comesou dar a
mensagem 1053 o serviço não respondeu a requisição de
On 06-04-2015 12:50, Franklin Anderson de Oliveira Souza wrote:
Galera aqui onde trabalho uma aplicação parou de de funcionar. O
responsável pelo o sistema (java) disse que nos logs mostravam um erro de
conexão com o banco. Sabendo disso olhei os logs do servidor postgresql e
observei o
Em 6 de abril de 2015 15:39, Fabrízio de Royes Mello
fabri...@timbira.com.br escreveu:
On 06-04-2015 12:50, Franklin Anderson de Oliveira Souza wrote:
LOG: unexpected EOF on client connection with an open transaction
Essas mensagens indicam que foi iniciada uma transação no PostgreSQL,
porém
Galera ! muito obrigado pelas dicas vou explorar a possibilidade de ser a
rede mesmo, pensei o seguinte, vou criar um script agendado no crontab pra
executar a cada minuto pra testar uma conexão com o banco de dados partindo
da aplicação, acho que com isso consigo provar que existe algo na rede
On 18-02-2015 15:05, Bruno Pio wrote:
Matheus e Fabrízio
Assim que possível, vou seguir os passos descritos para correção da
pg_statistic e remoção do registro dessa view na pg_catalog. Eu posto o
resultado quando o fizer.
Muito obrigado por enquanto pela ajuda!
Para complementar vc
2015-02-18 9:18 GMT-02:00 Bruno Pio brunocf...@gmail.com:
pg_dump: lendo esquemas
pg_dump: lendo tabelas definidas pelo usuário
pg_dump: esquema com OID 2848468115 não existe
Isso não é um bom sinal. Suspeito que tenha alguma relação corrompida. Sabe
se teve algum problema de hardware nesse
Matheus
Sobre a criação dessa view, sei que recentemente foram recriadas algumas
tabelas e populadas novamente nesse banco, se isso pode ter criado essa
view eu não sei, vou verificar como isso foi feito.
Sobre o pg_resetxlog, acredito ser muito difícil que alguém tenha feito
isso.
Matheus e
Teste
pg_dump: esquema com OID 2848468115 não existe
Isso não é um bom sinal. Suspeito que tenha alguma relação corrompida.
Sabe se teve algum problema de hardware nesse servidor ou algo fora do
comum recentemente?
Pode verificar o que retorna a seguinte consulta?
SELECT oid,
Matheus, bom dia!
Obrigado pelo rápido retorno
pg_dump: esquema com OID 2848468115 não existe
Isso não é um bom sinal. Suspeito que tenha alguma relação corrompida.
Sabe se teve algum problema de hardware nesse servidor ou algo fora do
comum recentemente?
Pode verificar o que retorna a
On 18-02-2015 14:18, Bruno Pio wrote:
O retorno desse SELECT foi:
2619;pg_statistic;13581757;r
Por curiosidade, eu executei um SELECT * FROM pg_statistic; que me retornou
o mesmo erro relatado anteriormente:
** Error **
ERRO: cabeçalho de página é inválido no bloco
2015-02-18 14:18 GMT-02:00 Bruno Pio brunocf...@gmail.com:
Quanto a consulta, o retorno foi:
13124322;nf_{ssdmed;13124322;v
Esse é um nome bem estranho, e no caso é uma view. Tem como saber no
histórico da aplicação algo sobre essa view? Está em uso? De onde veio? Etc.
Segundo o
2015-02-04 17:15 GMT-02:00 George Silva georger.si...@gmail.com:
Você instalou manual, digo, compilando o PostGIS?
No Ubuntu, rodar um ldconfig resolve. Se não resolver, crie um arquivo em
/etc/ld.so.conf.d com o nome geos.conf. Edite este arquivo e adicione o
diretório onde sua biblioteca
Você instalou manual, digo, compilando o PostGIS?
No Ubuntu, rodar um ldconfig resolve. Se não resolver, crie um arquivo em
/etc/ld.so.conf.d com o nome geos.conf. Edite este arquivo e adicione o
diretório onde sua biblioteca geos está residindo, no meu caso é:
/usr/local/lib.
Rode outro
On 26-01-2015 12:40, Fábio Gibon wrote:
Pessoal,
estou tendo o erro abaixo ao tentar ler uma determinada tabela:
ERROR: invalid memory alloc request size 18446744073709551610
E isto aconteceu há uma semana, eu identifiquei os registros com problemas,
removi, peguei de outro
Pessoal,
hoje, houve uma tentativa de reiniciar o banco atraves do comando
service postgresql restart, o banco parou e nao subiu mais, conforme
log abaixo:
LOG: terminating walsender process due to replication timeout
LOG: received fast shutdown request
LOG: aborting any active transactions
Você mandou o log do encerramento. Ele é absolutamente normal. O FATAL que
aparece é a mensagem enviada a uma das conexões pra avisá-la que o banco
foi encerrado no modo fast (cancelam-se as transações em andamento e
encerram-se a força as conexões).
Poderia nos mandar as mensagens que
Flavio Gurgel
Flavio,
estamos usando CentOS 6.3, PostgreSQL 9.1 instalado via repositorio PGDG.
O comando service postgresql start mostra a mensagem the database
system is shutting down.
Quando você utiliza o service postgresql start ele no log esta
apresentando the database system is
Glauco,
Quando você utiliza o service postgresql start ele no log esta apresentando
the database system is shutting down?
Sim.
==
Seu banco nesse momento esta OK?
Nao, quando a aplicacao tenta conectar, aparece a mesma mensagem de erro.
Assim como o
Quando você utiliza o service postgresql start ele no log esta
apresentando the database system is shutting down?
Sim.
==
Seu banco nesse momento esta OK?
Nao, quando a aplicacao tenta conectar, aparece a mesma mensagem
de erro.
Assim como o Flavio já te
A variável p_nome_tabela não foi declarada em nenhum local da function.
O parâmetro da function mais parecido é p_tabela, não era isso que vc
queria dizer?
Já são 9 da noite, hora de encerrar o expediente. Amanhã de manhã vc
enxerga melhor o código :]
--
Everton
2015-01-08 20:10 GMT-02:00
Pessoal,
o que significa o erro abaixo e o que fazer para evita-lo ?
PGRES_FATAL_ERROR - ERROR: deadlock detected
DETAIL: Process 16306 waits for ShareLock on transaction 110599693
blocked by process 16294.
Process 16294 waits for ShareLock on transaction 110599686 blocked by
process 16306.
SQL
Qual a saída de:
SELECT column_name, length(column_name) FROM information_schema.columns
WHERE table_schema = 'operational' AND table_name = 'technical';
?
--
Everton
On Tue, Dec 16, 2014 at 4:50 PM, Matheus Saraiva matheus.sara...@gmail.com
wrote:
O que há de errado com esse insert?:
Em 16/12/2014 19:50, Matheus Saraiva matheus.sara...@gmail.com escreveu:
O que há de errado com esse insert?:
insert into operational.technical(fullname, email, phone, image,
kmltraveled) values('Teste de inserção Manual', 'insercarman...@gmail.com',
'+5549', NULL, 0.0);
Recebo o
1 - 100 de 959 matches
Mail list logo