date:20150701

Re: [pgbr-geral] Timestamp With Time Zone

2015-07-01 Por tôpico Matheus de Oliveira

2015-07-01 13:38 GMT-03:00 Fernando Cambiaghi cambia...@gmail.com:

 Primeiro, creio que você está um pouco enganado, o PostgreSQL não está
 adicionando uma hora. Isso tudo vai depender de como você está inserindo o
 registro, veja que o tipo `timestamp WITH time zone` armazena o valor
 absoluto, e a conversão ao timezone é feito ao exibir. Dependendo do
 formato usado na inserção, pode-se ou não aparecer essa 1 hora a mais no
 resultado (difícil dizer sem mais detalhes).

 Então Matheus, na verdade eu não sei bem como o insert é feito. Eu
 realizo a transferência dos dados via PipeLine ( Objeto para este fim da
 ferramenta de programação Power Builder ), mas é basicamente ler os dados
 de uma fonte de dados e inserir em outra, como uma ferramenta de ETL, porém
 sem T, pois não transformo os dados. E os dados estão no banco PostgreSQL
 com 01 na hora, pois quando realizo uma consulta do tipo SELECT * FROM
 tabela WHERE campo_timestampz = '20150701' , os registros não são
 localizados, porém, ao alterar a consulta para SELECT * FROM tabela WHERE
 campo_timestampz = '20150701' and campo_timestampz  '20150702'  os
 resultados são apresentados,


Naturalmente.


 e com o campo_timestamp no seguinte formato 2015-07-01 01:00:00-03.
 ...


 Como eu já disse, não. Entretanto, dependendo de como você está
 informando os dados, você pode ter essa impressão. Por exemplo, se estiver
 usando um time zone offset ao invés do nome:

 postgres=# SELECT '2015-02-01 00:00:00-03:00'::timestamptz; -- errado
   timestamptz
 
  2015-02-01 01:00:00-02
 (1 row)

 postgres=# SELECT '2015-02-01 00:00:00
 America/Sao_Paulo'::timestamptz; -- correto
   timestamptz
 
  2015-02-01 00:00:00-02
 (1 row)

 Nas minhas aplicações eu não tenho este tipo de casting, nem poderia por
 enquanto, pois as aplicações ainda são para SGDB's diferentes. As consultas
 são realizadas conforme demonstrei mais acima.


Não é o CAST que é importante, mas sim o formato foi usado. Pegando por
exemplo a data que você passou (2015-07-01), se tivesse sido inserida
exatamente como '2015-07-01', ficaria:

postgres=# SELECT '2015-07-01'::timestamptz;
  timestamptz

 2015-07-01 00:00:00-03
(1 row)

E não com uma hora a mais como você citou. Mas isso só é verdade se a
aplicação que faz a inserção está usando exatamente o mesmo TimeZone que é
usado ao exibir os dados e não informa o TimeZone no literal (como eu fiz
no e-mail anterior). Por isso eu disse que não é o PostgreSQL que está
adicionando uma hora, é o formato da aplicação ou o TimeZone configurado
durante a inserção.

Eu faria o seguinte, converter de `timestamp WITH time zone` para
`timestamp WITHOUT time zone`, verifique se somente nesta conversão os
valores inseridos virão corretos (com meia noite). Caso ainda tenha
problemas, adicione uma trigger para fazer a correção (mas continue com
`timestamp WITHOUT time zone`, me parece melhor nesse caso).

OBS: Eu digo que `timestamp WITHOUT time zone`  é melhor como uma gambiarra
intermediária, o ideal NESSE CASO seria `date`. Na maioria das situações é
recomendado usa `timestamp WITH time zone` ao invés de WITHOUT.

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ajuda com for

2015-07-01 Por tôpico Alan Formagi

*Ótimo Douglas.*

Precisando de ajuda, sinalize. [?]

*Atenciosamente.*

*Alan Formagi*
*(47) 92034013 - Vivo*

Em 1 de julho de 2015 13:15, Douglas Fabiano Specht 
douglasfabi...@gmail.com escreveu:



 Em 1 de julho de 2015 12:59, Alan Formagi a...@formagi.com.br escreveu:

 *Boa tarde Douglas!*

 Pelo o que eu entendo essa estrutura vai ficar em loop.
 Toda vez que você inserir um registro a trigger tentará inserir
 outros, que por consequência irão disparar a mesma trigger, criando uma
 pilha. Sendo que é justamente isso que o postgres está reclamando quando
 te pede para incrementar a configuração max_stack_depth (
 http://www.postgresql.org/docs/8.3/static/runtime-config-resource.html).
 Uma solução é você adicionar um campo na tabela que identifique
 quando o registro é inserido pela trigger e quando é inserido pelo
 programa, e a partir disso fazer um tratamento dentro da função da trigger.
 Assim que eu tiver uns minutos eu vou tentar simular o caso na minha
 máquina, e se eu conseguir eu te mando um exemplo da solução.

 *Atenciosamente.*

 *Alan Formagi*
 *(47) 92034013 - Vivo*

 2015-07-01 11:43 GMT-03:00 Douglas Fabiano Specht 
 douglasfabi...@gmail.com:


 Pessoal
 preciso gerar uma trigger que quando tiver um insert ele duplique mais x
 vezes conforme o max de uma outra tabela, acho que esta em loop infinito,
 pois me da um erro: ERROR:  stack depth limit exceeded
 HINT:  Increase the configuration parameter max_stack_depth (currently
 2048kB), after ensuring the platform's stack depth limit is adequate.

 estou apanhando..alguem poderia me ajudar?
 postgres 9.4


 CREATE OR REPLACE FUNCTION dah.wdetcad() RETURNS TRIGGER AS $body$
 declare
 i integer;

 BEGIN
 for i in 1..(select max(codempresa) from configura  WHERE codhotel 1)
 loop
 INSERT INTO detcad
 select i, new.codgrupo, new.codfuncresp ;
  end loop;

 RETURN NEW();
 END;
 $body$
 LANGUAGE plpgsql;

 --

 Douglas Fabiano Specht

 ___
 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


 boa tarde
 obrigado a todos pela resposta,
 realmente o Alan matou a charada, como a trigger olhava no insert,e a
 propria trigger dava o insert ficava em loop,criei um campo de controle e
 funcionou.


 --

 Douglas Fabiano Specht

 ___
 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] ajuda com for

2015-07-01 Por tôpico Alan Formagi

*Douglas!*

Eu consegui simular o caso e achei uma solução.
Como citei no e-mail anterior, criei um campo na tabela que identifica
quando o registro é inserido pela trigger e quando é inserido pela
aplicação, em seguida tratei o caso com um IF dentro da trigger.
Compile o script em uma base em branco e faça os testes que necessitar.
Caso ainda necessite de apoio, me contate.

*Atenciosamente.*

*Alan Formagi*
*(47) 92034013 - Vivo*

Em 1 de julho de 2015 12:59, Alan Formagi a...@formagi.com.br escreveu:

 *Boa tarde Douglas!*

 Pelo o que eu entendo essa estrutura vai ficar em loop.
 Toda vez que você inserir um registro a trigger tentará inserir
 outros, que por consequência irão disparar a mesma trigger, criando uma
 pilha. Sendo que é justamente isso que o postgres está reclamando quando
 te pede para incrementar a configuração max_stack_depth (
 http://www.postgresql.org/docs/8.3/static/runtime-config-resource.html).
 Uma solução é você adicionar um campo na tabela que identifique quando
 o registro é inserido pela trigger e quando é inserido pelo programa, e a
 partir disso fazer um tratamento dentro da função da trigger.
 Assim que eu tiver uns minutos eu vou tentar simular o caso na minha
 máquina, e se eu conseguir eu te mando um exemplo da solução.

 *Atenciosamente.*

 *Alan Formagi*
 *(47) 92034013 - Vivo*

 2015-07-01 11:43 GMT-03:00 Douglas Fabiano Specht 
 douglasfabi...@gmail.com:


 Pessoal
 preciso gerar uma trigger que quando tiver um insert ele duplique mais x
 vezes conforme o max de uma outra tabela, acho que esta em loop infinito,
 pois me da um erro: ERROR:  stack depth limit exceeded
 HINT:  Increase the configuration parameter max_stack_depth (currently
 2048kB), after ensuring the platform's stack depth limit is adequate.

 estou apanhando..alguem poderia me ajudar?
 postgres 9.4


 CREATE OR REPLACE FUNCTION dah.wdetcad() RETURNS TRIGGER AS $body$
 declare
 i integer;

 BEGIN
 for i in 1..(select max(codempresa) from configura  WHERE codhotel 1)
 loop
 INSERT INTO detcad
 select i, new.codgrupo, new.codfuncresp ;
  end loop;

 RETURN NEW();
 END;
 $body$
 LANGUAGE plpgsql;

 --

 Douglas Fabiano Specht

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



--drop table config;
create table config (
num_max smallint);
insert into config(num_max) values(3);
--update config set num_max = 5;

--drop sequence sequencial;
CREATE SEQUENCE sequencial
  INCREMENT 1
  MINVALUE 1
  MAXVALUE 99
  START 1
  CACHE 1;

--drop table nomes;
create table nomes (
codigo bigint DEFAULT nextval('sequencial'::regclass)
   ,nome character varying (100)
   ,tipo boolean DEFAULT true);

--drop function inserir_nomes();
CREATE OR REPLACE FUNCTION inserir_nomes()
RETURNS trigger AS
$BODY$
Declare
_maximo smallint;
_nome nomes.nome%type;
_tipo boolean;
Begin

_tipo := NEW.tipo;

IF _tipo THEN
SELECT num_max
  INTO _maximo
  FROM config;

_nome := NEW.nome;
-- o seu máximo é 3, mas 1 registro você já inseriu
FOR i IN 1..(_maximo-1) LOOP
INSERT
  INTO nomes(nome, tipo)
VALUES(_nome, false);
END LOOP;

END IF;

return new;
End;
$BODY$
  LANGUAGE 'plpgsql' VOLATILE
  COST 100;

--DROP TRIGGER trg_inserir_max ON nomes;
CREATE TRIGGER trg_inserir_max
  AFTER INSERT
  ON NOMES
  FOR EACH ROW
  EXECUTE PROCEDURE inserir_nomes();

--insert into nomes(nome) values('Douglas Fabian Specht');
--select * from nomes;___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Timestamp With Time Zone

2015-07-01 Por tôpico Fernando Cambiaghi

Primeiro, creio que você está um pouco enganado, o PostgreSQL não está
adicionando uma hora. Isso tudo vai depender de como você está inserindo o
registro, veja que o tipo `timestamp WITH time zone` armazena o valor
absoluto, e a conversão ao timezone é feito ao exibir. Dependendo do
formato usado na inserção, pode-se ou não aparecer essa 1 hora a mais no
resultado (difícil dizer sem mais detalhes).

Então Matheus, na verdade eu não sei bem como o insert é feito. Eu
realizo a transferência dos dados via PipeLine ( Objeto para este fim da
ferramenta de programação Power Builder ), mas é basicamente ler os dados
de uma fonte de dados e inserir em outra, como uma ferramenta de ETL, porém
sem T, pois não transformo os dados. E os dados estão no banco PostgreSQL
com 01 na hora, pois quando realizo uma consulta do tipo SELECT * FROM
tabela WHERE campo_timestampz = '20150701' , os registros não são
localizados, porém, ao alterar a consulta para SELECT * FROM tabela WHERE
campo_timestampz = '20150701' and campo_timestampz  '20150702'  os
resultados são apresentados, e com o campo_timestamp no seguinte formato
2015-07-01 01:00:00-03.

Eu diria que você deveria urgentemente alterá-los para DATE. Uma etapa mais
suave seria alterar para timestamp, mas eu tentaria DATE somente e
verificaria como a aplicação se comporta, pode ser que não tenha tanta
coisa pra mudar na aplicação.
Ok e concordo. Providenciarei, mas terei muitos testes a fazer, então é uma
solução a longo prazo.


 Como eu já disse, não. Entretanto, dependendo de como você está informando
 os dados, você pode ter essa impressão. Por exemplo, se estiver usando um
 time zone offset ao invés do nome:

 postgres=# SELECT '2015-02-01 00:00:00-03:00'::timestamptz; -- errado
   timestamptz
 
  2015-02-01 01:00:00-02
 (1 row)

 postgres=# SELECT '2015-02-01 00:00:00
 America/Sao_Paulo'::timestamptz; -- correto
   timestamptz
 
  2015-02-01 00:00:00-02
 (1 row)

Nas minhas aplicações eu não tenho este tipo de casting, nem poderia por
enquanto, pois as aplicações ainda são para SGDB's diferentes. As consultas
são realizadas conforme demonstrei mais acima.




 Atenciosamente,
 --
 Matheus de Oliveira



 ___
 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

[pgbr-geral] Timestamp With Time Zone

2015-07-01 Por tôpico Fernando Cambiaghi

Bom dia.

Eu realizei a conversão de alguns bancos de dados para PostgreSQL e ainda
tenho vário para converter, porém, somente agora me deparei com um problema.

Temos várias tabelas com campo timestamp, que no PostgreSQL deixei como
timestampz. Esses campos foram criados assim a muito tempo atrás, e
atualmente ninguém sabe porque foram criados como timestamp, pois não são
utilizados para gravar hora, somente data, e inclusive são índices para
utilizar nas pesquisas com data.

Verificando as bases convertidas para PostgreSQL, reparei que essas datas
estão com hora 01 nos períodos de horário de verão, sendo que na base de
origem não estão, então isso está ocorrendo na transferência dos dados
entre as bases. Isso é um problema, pois as pesquisas procuram os registros
com parâmetros de data, e não encontra esses registros com hora 01.

Minhas perguntas são:

1. Como posso contornar essa situação, para que na carga dos dados o
PostgreSQL não trate horário de verão, mesmo os campos sendo do tipo
timestampz?

2. É muito ruim continuar utilizando os campos como timestampz ou eu
deveria urgentemente alterá-los para timestamp ou ainda para date, visto
que todas as aplicações teriam que ser testadas devido a declaração de
variáveis que são tipo datetime?

3. Ao entrar em horário de verão, o PostgreSQL irá começar a gravar as
datas com 01?

SO: Windows 7 32 Bits
PostgreSQL: 9.4.1

Agradeço antecipadamente a ajuda dos colegas.

Fernando Luís Cambiaghi
*cambia...@gmail.com cambia...@gmail.com*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] ajuda com for

2015-07-01 Por tôpico Douglas Fabiano Specht

Pessoal
preciso gerar uma trigger que quando tiver um insert ele duplique mais x
vezes conforme o max de uma outra tabela, acho que esta em loop infinito,
pois me da um erro: ERROR:  stack depth limit exceeded
HINT:  Increase the configuration parameter max_stack_depth (currently
2048kB), after ensuring the platform's stack depth limit is adequate.

estou apanhando..alguem poderia me ajudar?
postgres 9.4


CREATE OR REPLACE FUNCTION dah.wdetcad() RETURNS TRIGGER AS $body$
declare
i integer;

BEGIN
for i in 1..(select max(codempresa) from configura  WHERE codhotel 1)
loop
INSERT INTO detcad
select i, new.codgrupo, new.codfuncresp ;
 end loop;

RETURN NEW();
END;
$body$
LANGUAGE plpgsql;

-- 

Douglas Fabiano Specht
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ajuda com for

2015-07-01 Por tôpico Danilo Silva



 
 CREATE OR REPLACE FUNCTION dah.wdetcad() RETURNS TRIGGER AS $body$
 declare
 i integer;

 BEGIN
 for i in 1..(select max(codempresa) from configura  WHERE codhotel 1)
 loop
 INSERT INTO detcad
 select i, new.codgrupo, new.codfuncresp ;
  end loop;

 RETURN NEW();
 END;
 $body$
 LANGUAGE plpgsql;


Coloque o max em uma variável e a função ficaria: 


CREATE OR REPLACE FUNCTION dah.wdetcad() RETURNS TRIGGER AS $body$
declare
i integer;
vmax integer;

BEGIN
select max(codempresa) from configura  WHERE codhotel 1 INTO vmax;
for i in 1..vmax
loop
INSERT INTO detcad
select i, new.codgrupo, new.codfuncresp ;
 end loop;

RETURN NEW();
END;
$body$
LANGUAGE plpgsql;

Obs: não testei a função.

[]s
Danilo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida no Restore

2015-07-01 Por tôpico Euler Taveira

On 01-07-2015 13:11, Matheus de Oliveira wrote:
 
 2015-06-29 0:05 GMT-03:00 Aldrey Galindo aldreygali...@gmail.com
 mailto:aldreygali...@gmail.com:
 
Não tive problema no restore em si, mais pelo volume da base está
 demorando bastante. Notei que um dos processoa mais demorados está
 nos 'ALTER TABLE ... CONSTRAINT...'.
Gostaria de saber se vocês tem alguma recomendação para melhorar
 esse tempo. A configuração utilizada no restore está disponível
 aqui: http://pastebin.com/ru30uLwy
 
 
 Pelas suas configurações, você desabilitou o autovacuum, como está
 gargalando em comandos `ALTER TABLE ... ADD CONSTRAINT ...`, pode
 significar simplesmente que o plano de execução para validação de chaves
 estrangeiras esteja ruim, causando essa lentidão. Recomendo re-habilitar
 o autovacuum e verificar se melhora.
 
Eu não aconselho habilitar autovacuum em restaurações; a não ser que
você tenha uma base pequena ou não se importa com o tempo de
restauração. Na maioria dos casos ele prejudica a performance da operação.

O OP não detalhou o ... ADD CONSTRAINT ... Pode ser tanto criação de PK
quanto de FK. Se for o primeiro, com um m_w_m de 6GB as tabelas devem
ter dezenas ou centenas de gigabytes. No segundo caso, pode ser
múltiplas FKs numa mesma tabela grande ou algum plano ruim na
verificação da FK (é possível mas acho pouco provável já que é um
simples LEFT JOIN). Enfim, sem os comandos ALTER TABLE ... ADD
CONSTRAINT e uma saída do pg_stat_activity e/ou pg_locks que evidenciam
tais problemas fica difícil dizer o que está ocorrendo.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pgagent

2015-07-01 Por tôpico Rafael Fialho

Em 1 de julho de 2015 17:07, Douglas Fabiano Specht 
douglasfabi...@gmail.com escreveu:

 Pessoal,
 estou implementando via pgagent para disparar uma function de 1 em 1
 minuto,


Precisamos entender como foi realizada a instalação.
Estás com o processo pgagent rodando no seu servidor, e devidamente
configurado?
A aba Jobs aparece em seu pgAdmin?

ocorre que o esse job não está sendo disparado, tentei recriar e gerou o
 seguinte sql:

 INSERT INTO pgagent.pga_job (jobid, jobjclid, jobname, jobdesc,
 jobenabled, jobhostagent)
 SELECT JobId, jcl.jclid, 'enviaMensagem', '', true, 'localhost'
   FROM pgagent.pga_jobclass jcl WHERE jclname='Data Summarisation';


 INSERT INTO pgagent.pga_jobstep (jstid, jstjobid, jstname, jstdesc,
 jstenabled, jstkind, jstonerror, jstcode, jstdbname, jstconnstr)
  SELECT StpId, JobId, 'reenviaMensagem', '', true, 's', 'f', 'select
 smsdk.reenviaMensagem();', 'smsdk', '';
 INSERT INTO pgagent.pga_schedule (jscid, jscjobid, jscname, jscdesc,
 jscminutes, jschours, jscweekdays, jscmonthdays, jscmonths, jscenabled,
 jscstart, jscend)
 VALUES(SchId, JobId, 'reenviaMensagem', '',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}', '{t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t}', true, '2015-07-01 00:00:00', '2020-07-01
 00:00:00');


 onde eu acompanho o historico de execução? pois no pgadmin em statistics
 esta tudo em branco.


Na própria aba Jobs do pgAdmin é possível visualizar os jobs criados e
verificar quando foi a última tentativa de execução, se ocorreu sucesso ou
falha, etc.. Na tabela pgagent.pga_job também existe o campo joblastrun
para determinar quando foi a última vez que o job foi executado.
No seu caso, creio que ele não está sendo executado por falta de
inicialização e configuração do processo pgagent.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Timestamp With Time Zone

2015-07-01 Por tôpico Matheus de Oliveira

2015-07-01 11:12 GMT-03:00 Fernando Cambiaghi cambia...@gmail.com:

 1. Como posso contornar essa situação, para que na carga dos dados o
 PostgreSQL não trate horário de verão, mesmo os campos sendo do tipo
 timestampz?


Primeiro, creio que você está um pouco enganado, o PostgreSQL não está
adicionando uma hora. Isso tudo vai depender de como você está inserindo o
registro, veja que o tipo `timestamp WITH time zone` armazena o valor
absoluto, e a conversão ao timezone é feito ao exibir. Dependendo do
formato usado na inserção, pode-se ou não aparecer essa 1 hora a mais no
resultado (difícil dizer sem mais detalhes).


 2. É muito ruim continuar utilizando os campos como timestampz ou eu
 deveria urgentemente alterá-los para timestamp ou ainda para date, visto
 que todas as aplicações teriam que ser testadas devido a declaração de
 variáveis que são tipo datetime?


Eu diria que você deveria urgentemente alterá-los para DATE. Uma etapa mais
suave seria alterar para timestamp, mas eu tentaria DATE somente e
verificaria como a aplicação se comporta, pode ser que não tenha tanta
coisa pra mudar na aplicação.


 3. Ao entrar em horário de verão, o PostgreSQL irá começar a gravar as
 datas com 01?


Como eu já disse, não. Entretanto, dependendo de como você está informando
os dados, você pode ter essa impressão. Por exemplo, se estiver usando um
time zone offset ao invés do nome:

postgres=# SELECT '2015-02-01 00:00:00-03:00'::timestamptz; -- errado
  timestamptz

 2015-02-01 01:00:00-02
(1 row)

postgres=# SELECT '2015-02-01 00:00:00 America/Sao_Paulo'::timestamptz;
-- correto
  timestamptz

 2015-02-01 00:00:00-02
(1 row)

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pgagent

2015-07-01 Por tôpico Douglas Fabiano Specht

Em 1 de julho de 2015 20:02, Douglas Fabiano Specht 
douglasfabi...@gmail.com escreveu:



 Em 1 de julho de 2015 17:22, Rafael Fialho rafafial...@gmail.com
 escreveu:

 Em 1 de julho de 2015 17:07, Douglas Fabiano Specht 
 douglasfabi...@gmail.com escreveu:

 Pessoal,
 estou implementando via pgagent para disparar uma function de 1 em 1
 minuto,


 Precisamos entender como foi realizada a instalação.
 Estás com o processo pgagent rodando no seu servidor, e devidamente
 configurado?
 A aba Jobs aparece em seu pgAdmin?

 ocorre que o esse job não está sendo disparado, tentei recriar e gerou o
 seguinte sql:

 INSERT INTO pgagent.pga_job (jobid, jobjclid, jobname, jobdesc,
 jobenabled, jobhostagent)
 SELECT JobId, jcl.jclid, 'enviaMensagem', '', true, 'localhost'
   FROM pgagent.pga_jobclass jcl WHERE jclname='Data Summarisation';


 INSERT INTO pgagent.pga_jobstep (jstid, jstjobid, jstname, jstdesc,
 jstenabled, jstkind, jstonerror, jstcode, jstdbname, jstconnstr)
  SELECT StpId, JobId, 'reenviaMensagem', '', true, 's', 'f', 'select
 smsdk.reenviaMensagem();', 'smsdk', '';
 INSERT INTO pgagent.pga_schedule (jscid, jscjobid, jscname, jscdesc,
 jscminutes, jschours, jscweekdays, jscmonthdays, jscmonths, jscenabled,
 jscstart, jscend)
 VALUES(SchId, JobId, 'reenviaMensagem', '',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}', '{t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t}', true, '2015-07-01 00:00:00', '2020-07-01
 00:00:00');


 onde eu acompanho o historico de execução? pois no pgadmin em statistics
 esta tudo em branco.


 Na própria aba Jobs do pgAdmin é possível visualizar os jobs criados e
 verificar quando foi a última tentativa de execução, se ocorreu sucesso ou
 falha, etc.. Na tabela pgagent.pga_job também existe o campo joblastrun
 para determinar quando foi a última vez que o job foi executado.
 No seu caso, creio que ele não está sendo executado por falta de
 inicialização e configuração do processo pgagent.

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


 Rafael
 consegui pegar o log, acho que é algo sobre autenticação:
 WARNING: Failed to create new connection to database
 'mensagem':'fe_sendauth: no password supplied'

 no debian onde configuro o pgpass? soachei referencia para windows..


 --

 Douglas Fabiano Specht


Encontrei..
no /home/postgres/.pgpass
ja funcionando

-- 

Douglas Fabiano Specht
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pgagent

2015-07-01 Por tôpico Douglas Fabiano Specht

Em 1 de julho de 2015 17:22, Rafael Fialho rafafial...@gmail.com escreveu:

 Em 1 de julho de 2015 17:07, Douglas Fabiano Specht 
 douglasfabi...@gmail.com escreveu:

 Pessoal,
 estou implementando via pgagent para disparar uma function de 1 em 1
 minuto,


 Precisamos entender como foi realizada a instalação.
 Estás com o processo pgagent rodando no seu servidor, e devidamente
 configurado?
 A aba Jobs aparece em seu pgAdmin?

 ocorre que o esse job não está sendo disparado, tentei recriar e gerou o
 seguinte sql:

 INSERT INTO pgagent.pga_job (jobid, jobjclid, jobname, jobdesc,
 jobenabled, jobhostagent)
 SELECT JobId, jcl.jclid, 'enviaMensagem', '', true, 'localhost'
   FROM pgagent.pga_jobclass jcl WHERE jclname='Data Summarisation';


 INSERT INTO pgagent.pga_jobstep (jstid, jstjobid, jstname, jstdesc,
 jstenabled, jstkind, jstonerror, jstcode, jstdbname, jstconnstr)
  SELECT StpId, JobId, 'reenviaMensagem', '', true, 's', 'f', 'select
 smsdk.reenviaMensagem();', 'smsdk', '';
 INSERT INTO pgagent.pga_schedule (jscid, jscjobid, jscname, jscdesc,
 jscminutes, jschours, jscweekdays, jscmonthdays, jscmonths, jscenabled,
 jscstart, jscend)
 VALUES(SchId, JobId, 'reenviaMensagem', '',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}', '{t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t}',
 '{t,t,t,t,t,t,t,t,t,t,t,t}', true, '2015-07-01 00:00:00', '2020-07-01
 00:00:00');


 onde eu acompanho o historico de execução? pois no pgadmin em statistics
 esta tudo em branco.


 Na própria aba Jobs do pgAdmin é possível visualizar os jobs criados e
 verificar quando foi a última tentativa de execução, se ocorreu sucesso ou
 falha, etc.. Na tabela pgagent.pga_job também existe o campo joblastrun
 para determinar quando foi a última vez que o job foi executado.
 No seu caso, creio que ele não está sendo executado por falta de
 inicialização e configuração do processo pgagent.

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Rafael
consegui pegar o log, acho que é algo sobre autenticação:
WARNING: Failed to create new connection to database
'mensagem':'fe_sendauth: no password supplied'

no debian onde configuro o pgpass? soachei referencia para windows..


-- 

Douglas Fabiano Specht
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Timestamp With Time Zone

Re: [pgbr-geral] ajuda com for

Re: [pgbr-geral] ajuda com for

Re: [pgbr-geral] Timestamp With Time Zone

[pgbr-geral] Timestamp With Time Zone

[pgbr-geral] ajuda com for

Re: [pgbr-geral] ajuda com for

Re: [pgbr-geral] Dúvida no Restore

Re: [pgbr-geral] pgagent

Re: [pgbr-geral] Timestamp With Time Zone

Re: [pgbr-geral] pgagent

Re: [pgbr-geral] pgagent

12 matches

Site Navigation

Mail list logo

Footer information