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
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.
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:
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
>&
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
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 =
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
