from:"Ronaldo Bernardes Pereira"

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-28 Por tôpico Ronaldo Bernardes Pereira

Alexsander, boa noite


Criei meu próprio exemplo para entender seu problema e chegar em uma
conclusão do que está ocorrendo.

--=== Criei uma tabela para teste a partir do generate_series

create table analyze_query as select
gn::character(20),'SomeTextExample'::text from generate_series(1,1000)
gn;


postgres=# \d analyze_query
 Tabela "public.analyze_query"
 Coluna | Tipo  | Modificadores
+---+---
 gn | character(10) |
 text   | text  |


--=== verificando o tamanho da tabela

postgres=# \dt+ analyze_query
 Lista de relações
 Esquema | Nome  |  Tipo  |   Dono   | Tamanho | Descrição
-+---++--+-+---
 public  | analyze_query | tabela | postgres | 574 MB  |


--=== Criei um index na coluna gn

create unique index on analyze_query(gn);


--=== Criei uma  FUNCTION parecida com a sua com o tipo do
argumento text

CREATE OR REPLACE FUNCTION sp_teste1(chave text)
 RETURNS text
 LANGUAGE plpgsql
AS $$
DECLARE
BEGIN
  PERFORM gn FROM analyze_query WHERE gn = chave;
  Return 'OK';
END;
$$;


--=== Executei o explain em um select parecido com o seu, para
comprovar que o índice seria usado

postgres=#  explain select gn FROM analyze_query WHERE gn ='900';
   QUERY PLAN

 Index Only Scan using analyze_query_gn_idx on analyze_query
(cost=0.43..8.45 rows=1 width=14)
   Index Cond: (gn = '900'::bpchar)
(2 registros)

--=== Query com tempo de execução

postgres=# select gn FROM analyze_query WHERE gn ='900';
 gn

 900
Tempo: 0,240 ms


--=== FUNCTION com tempo de execução, nesse caso o tempo foi muito
maior

postgres=# select sp_teste1('900');
 sp_teste1
---
 OK
(1 registro)

Tempo: 3144,483 ms

--===  Fiz o load do módulo auto explain para gerar plano de
execução automatico, tanto na tela como log do PostgreSQL.


LOAD 'auto_explain';
SET auto_explain.log_analyze TO on;
SET auto_explain.log_min_duration TO 0;
SET auto_explain.log_nested_statements TO on;
SET client_min_messages TO log;


--===  Executei a FUNCTION sp_teste1

Tempo: 16,121 ms
postgres=# select sp_teste1('900');
LOG:  duration: 3123.277 ms  plan:
Query Text: SELECT gn FROM analyze_query WHERE gn = chave
Seq Scan on analyze_query  (cost=0.00..223530.00 rows=5 width=14)
(actual time=2819.195..3123.258 rows=1 loops=1)
  Filter: ((gn)::text = '900'::text)
  Rows Removed by Filter: 999
CONTEXTO:  comando SQL "SELECT gn FROM analyze_query WHERE gn = chave"
função PL/pgSQL sp_teste1(text) linha 4 em PERFORM
LOG:  duration: 3123.736 ms  plan:
Query Text: select sp_teste1('900');
Result  (cost=0.00..0.26 rows=1 width=0) (actual time=3123.713..3123.716
rows=1 loops=1)
 sp_teste1
---
 OK
(1 registro)

Tempo: 3124,263 ms


--===   Plano  da query da FUNCTION sp_teste1, comprovando que
houve o seq scan

Seq Scan on analyze_query  (cost=0.00..223530.00 rows=5 width=14)
(actual time=2819.195..3123.258 rows=1 loops=1)
Filter: ((gn)::text = '900'::text)


--=== Alterei o argumento de (chave text) para (chave character(10))

CREATE OR REPLACE FUNCTION sp_teste2(chave character(10))
 RETURNS text
 LANGUAGE plpgsql
AS $$
DECLARE
BEGIN
  PERFORM gn FROM analyze_query WHERE gn = chave;
  Return 'OK';
END;
$$;


 --===  Fiz o teste também fazendo o CAST explicito e funcionou,
perfeitamente também como no exemplo anterior

 CREATE OR REPLACE FUNCTION sp_teste1(chave text)
 RETURNS text
 LANGUAGE plpgsql
AS $$
DECLARE
BEGIN
  PERFORM gn FROM analyze_query WHERE gn = chave::bpchar;  <<--- CAST
explicito
  Return 'OK';
END;
$$;

 --===   Executei novamente (Novo caso)


postgres=# select sp_teste2('900');
LOG:  duration: 0.292 ms  plan:
Query Text: SELECT gn FROM analyze_query WHERE gn = chave
Index Only Scan using analyze_query_gn_idx on analyze_query
(cost=0.43..8.45 rows=1 width=14) (actual time=0.264..0.267 rows=1 loops=1)
  Index Cond: (gn = '900'::bpchar)
  Heap Fetches: 1
CONTEXTO:  comando SQL "SELECT gn FROM analyze_query WHERE gn = chave"
função PL/pgSQL sp_teste3(character) linha 4 em PERFORM
LOG:  duration: 0.955 ms  plan:
Query Text: select sp_teste2('900');
Result  (cost=0.00..0.26 rows=1 width=0) (actual time=0.934..0.936 rows=1
loops=1)
 sp_teste3
---
 OK
(1 registro)


 --=== duration com a mudança tanto no argumento, como no CAST
explicito

LOG:  duration: 0.955 ms  plan:


Index Only Scan using analyze_query_gn_idx on analyze_query
(cost=0.43..8.45 rows=1 width=14) (actual time=0.264..0.267 rows=1 loops=1)
  Index Cond: (gn = '900'::bpchar)


 --=== Executar novamente (Caso antigo)


postgres=# select sp_teste1('900');
LOG:  duration: 3141.335 ms  plan:
Query

Re: [pgbr-geral] connect: Bad file descriptor

2015-12-23 Por tôpico Ronaldo Bernardes Pereira

Fernando, boa noite

Essa função é criada quando o invasor tem acesso ao usuário postgres. A
partir dai, o invasor pode usar o comando copy para ler arquivos do Linux
para o banco de dados, criar funções que criam arquivos e por ai vai. Te
passei o link do site, pois suspeitava desse problema.

Confira esse vídeo demonstrando como realizar o hack no PostgreSQL para
você entender o que o invasor pode ter feito:
https://www.youtube.com/watch?v=n9i5kjPDg2M

Sempre é bom entender quais a técnicas que estão sendo utilizadas para
invasão e assim buscar formas efetivas de melhorar a proteção do SGBD
PostgreSQL, ainda mais quando o banco de dados está disponível na web.

Como falei anteriormente na empresa onde encontrei o exploit começaram a
reclamar de lentidão. Por incrível que pareça, constatei que o pg_hba.conf
estava aberto para todos os usuários em todos os bancos e com o método de
conexão trust. Não preciso nem explicar o resto.



Em 22 de dezembro de 2015 08:42, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

>
> Verificando o que os colegas comentaram,  identifiquei o possível
>> problema.
>>
>> http://unix.stackexchange.com/a/248010
>>
>> Havia a função exec111 no database postgres, essa função tentava
>> executar um arquivo no /tmp, porem esse arquivo não existe lá.
>>
>> Alterando todas senhas.
>>
>
> Eu acrescentaria os gerúndios abaixo:
> Congelando a máquina fora da rede, fazendo dump completo, instalando novo
> servidor limpo para os dados, com mais proteção e restaurando o dump nele
> pra colocar o serviço em produção em seguida.
>
> E se tiver grana pra tal, fazer uma análise forense pra entender de onde
> pode ter vindo.
>
> []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] connect: Bad file descriptor

2015-12-21 Por tôpico Ronaldo Bernardes Pereira

Fernando, boa noite

Vi algo parecido em um SGBD PostgreSQL Linux de uma empresa e constatei que
a máquina tinha um exploit gerando o mesmo erro no log. Você verificou se a
/tmp tem arquivos suspeitos? (ls -ltra /tmp)

Olha um exemplo:
http://unix.stackexchange.com/questions/246735/releasing-a-deleted-but-open-log-file

Veja se aparece erros estranhos em /var/log/messages

Em 21 de dezembro de 2015 14:29, Fernando Manchini <
fernandomanch...@gmail.com> escreveu:

>
> Em 21 de dezembro de 2015 14:21, Flavio Henrique Araque Gurgel <
> fha...@gmail.com> escreveu:
>
>> Especificamente o comando :
>>> ls -l /tmp/.s.PGSQL.5432
>>>
>>> Retorna:
>>> ls: não é possível acessar /tmp/.s.PGSQL.5432: Arquivo ou
>>> diretório não
>>> encontrado
>>>
>>>
>>> Mas executando:
>>>
>>> ls -l /run/postgresql/.s.PGSQL.5432
>>> srwxrwxrwx 1 postgres postgres 0 Dez 21 13:44
>>> /run/postgresql/.s.PGSQL.5432
>>>
>>>
>>> Está correto, esqueci que em Debian/Ubuntu colocaram o socket em
>>> outro local. Mas tem todas as permissões, está ok.
>>>
>>> Pergunto: Você usa algum tipo de conexão a partir do lado do servidor,
>>> como FDW ou DBLINK ?
>>>
>>> Não.
>>>
>>
>> Minhas últimas ideias :
>> 1) Você consegue identificar o momento em que as mensagens começaram a
>> aparecer, e relacionar a alguma coisa que tenha alterado em seu banco de
>> dados?
>> 2) Essa máquina tem algum mecanismo de controle, como SELinux ou quotas
>> de disco?
>>
>>
>> []s
>> Flavio Gurgel
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
> Vou tentar verificar.
>
> Mas a mensagem:
>
> "connect: Bad file descriptor"
>
> Está relacionada a conexão ?
> Não seria algum arquivo do banco corrompido   ?
>** Se fosse o caso, creio que seria algo " could not read block... "
>
>
>
> ___
> 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] Busca pelo arquivo .history apos recovery

2015-11-09 Por tôpico Ronaldo Bernardes Pereira

Franklin, boa noite

Para voltar um PITR altero o arquivo postgresql.conf e desativo o
archive_command e outros parâmetros, caso o servidor seja diferente do
original. Creio que você está voltando o PITR em outro servidor, pois no
log aparece o erro "No such file or directory". Nesse caso acho que o
diretório não existe ou o Postgres não tem permissão no diretório. Após
todo o sucesso de recuperação do servidor reativo o archive.

Att,



Em 9 de novembro de 2015 21:29, Franklin Anderson de Oliveira Souza <
frankli...@gmail.com> escreveu:

> Olá Ronaldo !!
>
> Está sim ativado, será esse o motivo  !?
>
>
> Em segunda-feira, 9 de novembro de 2015, Ronaldo Bernardes Pereira <
> ronaldobernar...@gmail.com> escreveu:
>
>> Franklin, boa noite
>>
>> No arquivo postgresql. conf antes de você iniciar o recovery, o parâmetro
>> archive_command  está ativado?
>>
>>
>> 2015-11-09 19:58 GMT-02:00 Franklin Anderson de Oliveira Souza <
>> frankli...@gmail.com>:
>>
>>> Olá Colegas !
>>>
>>> Em meus estudos e tentativas de recovery (PITR) tenho encontrado a
>>> seguinte mensagem nos logs após um recovery supostamente bem sucedido:
>>>
>>> --
>>> 2015-11-09 18:44:34 AMST [38358]: [864-1] user=,db=,client= LOG:
>>>  archive command failed with exit code 1
>>> 2015-11-09 18:44:34 AMST [38358]: [865-1] user=,db=,client= DETAIL:  The
>>> failed archive command was: test ! -f /wals/0002.history && cp
>>> pg_xlog/0002.history /wals/0002.history
>>> cp: cannot create regular file `/wals/0002.history': No such file or
>>> directory
>>> 2015-11-09 18:44:35 AMST [38358]: [866-1] user=,db=,client= LOG:
>>>  archive command failed with exit code 1
>>> 2015-11-09 18:44:35 AMST [38358]: [867-1] user=,db=,client= DETAIL:  The
>>> failed archive command was: test ! -f /wals/0002.history && cp
>>> pg_xlog/0002.history /wals/0002.history
>>> 2015-11-09 18:44:35 AMST [38358]: [868-1] user=,db=,client= WARNING:
>>>  archiving transaction log file "0002.history" failed too many times,
>>> will try again later
>>> cp: cannot create regular file `/wals/0002.history': No such file or
>>> directory
>>> 2015-11-09 18:45:36 AMST [38358]: [869-1] user=,db=,client= LOG:
>>>  archive command failed with exit code 1
>>> 2015-11-09 18:45:36 AMST [38358]: [870-1] user=,db=,client= DETAIL:  The
>>> failed archive command was: test ! -f /wals/0002.history && cp
>>> pg_xlog/0002.history /wals/0002.history
>>> cp: cannot create regular file `/wals/0002.history': No such file or
>>> directory
>>> 2015-11-09 18:45:37 AMST [38358]: [871-1] user=,db=,client= LOG:
>>>  archive command failed with exit code 1
>>> 2015-11-09 18:45:37 AMST [38358]: [872-1] user=,db=,client= DETAIL:  The
>>> failed archive command was: test ! -f /wals/0002.history && cp
>>> pg_xlog/0002.history /wals/0002.history
>>> cp: cannot create regular file `/wals/0002.history': No such file or
>>> directory
>>> 2015-11-09 18:45:38 AMST [38358]: [873-1] user=,db=,client= LOG:
>>>  archive command failed with exit code 1
>>> 2015-11-09 18:45:38 AMST [38358]: [874-1] user=,db=,client= DETAIL:  The
>>> failed archive command was: test ! -f /wals/0002.history && cp
>>> pg_xlog/0002.history /wals/0002.history
>>> 2015-11-09 18:45:38 AMST [38358]: [875-1] user=,db=,client= WARNING:
>>>  archiving transaction log file "0002.history" failed too many times,
>>> will try again later
>>> --
>>>
>>> Digo bem sucedido porque quando observo manualmente o resultado do
>>> recovery, os dados estão perfeitamente integros. Como posso intepretar essa
>>> mensagem do log. É um erro ?! esta faltando algo ?! Tem algum procedimento
>>> ainda pedente ?!
>>>
>>> Obrigado pelas respostas.
>>>
>>>
>>> --
>>> foobar
>>>
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>
>>
>
> --
> Enviado do Gmail para celular
>
> ___
> 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] Busca pelo arquivo .history apos recovery

2015-11-09 Por tôpico Ronaldo Bernardes Pereira

Franklin, boa noite

No arquivo postgresql. conf antes de você iniciar o recovery, o parâmetro
archive_command  está ativado?


2015-11-09 19:58 GMT-02:00 Franklin Anderson de Oliveira Souza <
frankli...@gmail.com>:

> Olá Colegas !
>
> Em meus estudos e tentativas de recovery (PITR) tenho encontrado a
> seguinte mensagem nos logs após um recovery supostamente bem sucedido:
>
> --
> 2015-11-09 18:44:34 AMST [38358]: [864-1] user=,db=,client= LOG:  archive
> command failed with exit code 1
> 2015-11-09 18:44:34 AMST [38358]: [865-1] user=,db=,client= DETAIL:  The
> failed archive command was: test ! -f /wals/0002.history && cp
> pg_xlog/0002.history /wals/0002.history
> cp: cannot create regular file `/wals/0002.history': No such file or
> directory
> 2015-11-09 18:44:35 AMST [38358]: [866-1] user=,db=,client= LOG:  archive
> command failed with exit code 1
> 2015-11-09 18:44:35 AMST [38358]: [867-1] user=,db=,client= DETAIL:  The
> failed archive command was: test ! -f /wals/0002.history && cp
> pg_xlog/0002.history /wals/0002.history
> 2015-11-09 18:44:35 AMST [38358]: [868-1] user=,db=,client= WARNING:
>  archiving transaction log file "0002.history" failed too many times,
> will try again later
> cp: cannot create regular file `/wals/0002.history': No such file or
> directory
> 2015-11-09 18:45:36 AMST [38358]: [869-1] user=,db=,client= LOG:  archive
> command failed with exit code 1
> 2015-11-09 18:45:36 AMST [38358]: [870-1] user=,db=,client= DETAIL:  The
> failed archive command was: test ! -f /wals/0002.history && cp
> pg_xlog/0002.history /wals/0002.history
> cp: cannot create regular file `/wals/0002.history': No such file or
> directory
> 2015-11-09 18:45:37 AMST [38358]: [871-1] user=,db=,client= LOG:  archive
> command failed with exit code 1
> 2015-11-09 18:45:37 AMST [38358]: [872-1] user=,db=,client= DETAIL:  The
> failed archive command was: test ! -f /wals/0002.history && cp
> pg_xlog/0002.history /wals/0002.history
> cp: cannot create regular file `/wals/0002.history': No such file or
> directory
> 2015-11-09 18:45:38 AMST [38358]: [873-1] user=,db=,client= LOG:  archive
> command failed with exit code 1
> 2015-11-09 18:45:38 AMST [38358]: [874-1] user=,db=,client= DETAIL:  The
> failed archive command was: test ! -f /wals/0002.history && cp
> pg_xlog/0002.history /wals/0002.history
> 2015-11-09 18:45:38 AMST [38358]: [875-1] user=,db=,client= WARNING:
>  archiving transaction log file "0002.history" failed too many times,
> will try again later
> --
>
> Digo bem sucedido porque quando observo manualmente o resultado do
> recovery, os dados estão perfeitamente integros. Como posso intepretar essa
> mensagem do log. É um erro ?! esta faltando algo ?! Tem algum procedimento
> ainda pedente ?!
>
> Obrigado pelas respostas.
>
>
> --
> foobar
>
> ___
> 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] pg_log parâmetros de coleta de logs

2015-11-09 Por tôpico Ronaldo Bernardes Pereira

Joel, boa noite

Não sei se entendi a duvida, mas geralmente configuro o que aparecerá no
log dessa forma:

log_line_prefix = '%p | %t | %u | %d'


Parâmetros que podem ser utilizados. **Verificar a versão do
PostgreSQL, pois pequei esse parâmetros na web

 #   %u = user name
 #   %d = database name
 #   %r = remote host and port
 #   %h = remote host
 #   %p = PID
 #   %t = timestamp (no milliseconds)
 #   %m = timestamp with milliseconds
 #   %i = command tag
 #   %c = session id
 #   %l = session line number
 #   %s = session start timestamp
 #   %x = transaction id
 #   %q = stop here in non-session
 #processes
 #   %% = '%'
 # e.g. '<%u%%%d> '


Quanto a quantidade de log, você pode mudar a configuração do
parâmetro log_statement no arquivo postgresql.conf, nesse caso para
none, somente irei logar erros e nada mais.


log_statement = 'none'   # none, ddl, mod, all

O segredo está em alterar o parâmetro log_statement no database ou no
usuário, de forma que você log somente o essencial, ou seja, o que
você quiser logar.

No caso do database, todo mundo que conectar no database que foi
alterado o parâmetro log_statement, automaticamente será logado na
forma que foi determinado.

Ex1: alter database nomedatabase set log_statement to 'all';
# para logar tudo ou 'ddl' para modificação de objetos, ou 'mod' (
acho que é para comandos de insert, update, delete).

Nesse caso será logado tudo o que o usuário executar no banco a partir
do momento que ele conectar.

Ex2: alter role rolename set log_statement to 'all';
# none, ddl, mod, all

É claro existe outros tipos de log que você pode ativar no PostgreSQL,
conforme explicação dada pelo Euler Taveira.

Esse por exemplo pode enganar na hora de logar, pois se ficar setado
como 0 loga tudo também, mesmo tendo log_statement como 'none'.

#log_min_duration_statement = -1 # -1 is disabled, 0 logs all statements




Att,





Em 9 de novembro de 2015 13:50, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2015-11-09 13:45 GMT-02:00 Joel Benelli :
> > De fato Guimarães, bem exagerado, o servidor atende duas equipes de
> > desenvolvimento, suporte técnico, e setor de projetos de vário produtos,
> > ..., caos ...
>
> Imagino!
>
> Quando vivi algo assim, a gente conseguir controlar um pouco com o uso
> judicioso de esquemas, com um sistema de nomenclatura para facilitar.
>
>
> --
> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> ___
> 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] Erro pg_restore

2015-10-21 Por tôpico Ronaldo Bernardes Pereira

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 datahora_transacao.
Nesse caso, no Windows o backup deverá ser realizado com formato custom
(-Fc) que realizar compactação do dump. O dump pode realizado de uma versão
menor para maior, mas creio que não pode ser o inverso. O dumo em formato
plain(texto puro), restaura normalmente com caracteres estranhos  em SGBDs
PostgreSQL (Linux), pois já executei vários testes com sucesso. Como disse,
somente no Windows acontece esse tipo de erro, mas que pode ser contornado
sem problemas.



Em 20 de outubro de 2015 09:49, Rudimar  escreveu:

>
> 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 menor,
>> parece que ele compacta o arquivo é isso mesmo?... o problema estava no
>> "tar" mesmo...
>>
>> preciso rever meus conceitos de dumps e backups...
>>
>>
>>
>> Rudimar.
>>
>> Em 19 de outubro de 2015 16:06, Douglas Ghirelli <
>> douglasghire...@gmail.com> escreveu:
>>
>>> Boa tarde,
>>>
>>> Já tive esse problema utilizando Windows e formato tar, já tentou com o
>>> format custom ?
>>>
>>> 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 "public.vendas" "db"
 pg_dump: lendo esquemas
 pg_dump: lendo tabelas definidas pelo usuÃ¡rio
 pg_dump: lendo extensÃµes
 pg_dump: lendo funÃ§Ãµes definidas pelo usuÃ¡rio
 pg_dump: lendo tipos definidos pelo usuÃ¡rio
 pg_dump: lendo linguagens procedurais
 pg_dump: lendo funÃ§Ãµes de agregaÃ§Ã£o definidas pelo usuÃ¡rio
 pg_dump: lendo operadores definidos pelo usuÃ¡rio
 pg_dump: lendo classes de operadores definidas pelo usuÃ¡rio
 pg_dump: lendo famÃlias de operadores definidas pelo usuÃ¡rio
 pg_dump: lendo analisadores de busca textual definidos pelo usuÃ¡rio
 pg_dump: lendo modelos de busca textual definidos pelo usuÃ¡rio
 pg_dump: lendo dicionÃ¡rios de busca textual definidos pelo usuÃ¡rio
 pg_dump: lendo configuraÃ§Ãµes de busca textual definidas pelo usuÃ¡rio
 pg_dump: lendo adaptadores de dados externos definidos pelo usuÃ¡rio
 pg_dump: lendo servidores externos definidos pelo usuÃ¡rio
 pg_dump: lendo privilÃ©gios padrÃ£o
 pg_dump: lendo ordenaÃ§Ãµes definidas pelo usuÃ¡rio
 pg_dump: lendo conversÃµes definidas pelo usuÃ¡rio
 pg_dump: lendo conversÃµes de tipo
 pg_dump: lendo informaÃ§Ã£o de heranÃ§a das tabelas
 pg_dump: lendo gatilhos de eventos
 pg_dump: encontrando membros de extensÃµes
 pg_dump: encontrando relacionamentos herdados
 pg_dump: lendo informaÃ§Ãµes das colunas em tabelas interessantes
 pg_dump: encontrando as colunas e tipos da tabela "vendas"
 pg_dump: marcando colunas herdadas nas subtabelas
 pg_dump: lendo Ãndices
 pg_dump: lendo Ãndices da tabela "vendas"
 pg_dump: lendo restriÃ§Ãµes
 pg_dump: lendo gatilhos
 pg_dump: lendo regras de reescrita
 pg_dump: lendo dados sobre dependÃªncia
 pg_dump: salvando codificaÃ§Ã£o = UTF8
 pg_dump: salvando padrÃ£o de escape de cadeia de caracteres = on
 pg_dump: copiando conteÃºdo da tabela vendas

 Process returned exit code 0.




 Na verdade, da erro nessa tabela somente, quando restauro o banco
 completo... e tenho outra tabela de 4GB e sem problema ao restaurar no
 9.4..



 Em 19 de outubro de 2015 15:48, Sebastian Webber 
 escreveu:

>
>
> Em 19 de outubro de 2015 14:49, Rudimar 
> escreveu:
>
>>
>> Pessoal,
>>
>
> Boa tarde!
>
>
>>
>> estou com problema ao dar um pg_dump e restaurar pg_restore,
>> exportando do 9.3 e importando no 9.4
>>
>> tabela é mesma tudo igual, mas parece que alguma coisa desloca linha
>> no arquivo backup, e desloca os dados algum assim,
>>
>> a tabela tem uns 4,4GB  (22milhões de registro)
>>
>> havia somente uma coluna texto, removi ela pensado que era algum
>> acento alguma coisa, até resolveu o erro que era em outra linha, agora 
>> tem
>> esse, só tem campos números e data.
>>
>>
>>
>> D:/Program Files/PostgreSQL/9.4/bin\pg_restore.exe --host localhost
>> --port 5432 --username "postgres" --dbname "sulcard"

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

Re: [pgbr-geral] connect: Bad file descriptor

Re: [pgbr-geral] connect: Bad file descriptor

Re: [pgbr-geral] Busca pelo arquivo .history apos recovery

Re: [pgbr-geral] Busca pelo arquivo .history apos recovery

Re: [pgbr-geral] pg_log parâmetros de coleta de logs

Re: [pgbr-geral] Erro pg_restore

7 matches

Site Navigation

Mail list logo

Footer information