Olá Fabrízio, Obrigado pela resposta.
De fato não é a melhor solução, mas o que ocorre é que realmente a app está fazendo isso de forma indevida, e fica esquecendo estas sessios por lá. O correto seria ajustar no código, porém, infelizmente a instituição que desenvolveu app não está disposto a fazer tal análise. Em 12 de maio de 2015 17:13, Fabrízio de Royes Mello < [email protected]> escreveu: > On 12-05-2015 16:23, Francisco Porfirio wrote: > > Olá Pessoal, > > > > Tenho um cenário em que a aplicação de produção deixa com frequencia > > sessions prepared no banco. De forma que o paliativo para não causar > mais > > indisponibilidade seria construir uma function, onde verificaria se a > > session prepared estaria a mais de X minutos, em caso afirmativo seria > > executado o rollback prepared. > > > > Construi a function abaixo, porém ao executar no banco em que existe a > > session prepared simplesmente o rollback não é feito. Caso alguém possa > > ajudar ficaria agradecido > > > > CREATE or replace FUNCTION remove_prepared() RETURNS text AS $$ > > DECLARE > > var_qtd_prepared integer; > > varre record; > > text_var1 text; > > text_var2 text; > > text_var3 text; > > var_command_string text; > > BEGIN > > > > select count(1) > > into var_qtd_prepared > > from pg_prepared_XACTS; > > > > if (var_qtd_prepared > 0) then > > > > for varre in ( SELECT gid, prepared, database > > FROM pg_prepared_XACTS > > where age(now(),prepared) >= '30 minutes' > > ) > > loop > > > > begin > > RAISE INFO 'Database: %',varre.database; > > RAISE INFO 'Prepared: %',varre.prepared; > > RAISE INFO 'Gid: %',varre.gid; > > > > var_command_string := 'ROLLBACK PREPARED > '''||varre.gid||''''; > > > > RAISE INFO '%',var_command_string; > > execute var_command_string; > > RAISE INFO '-----------------------------------'; > > exception when others then > > GET STACKED DIAGNOSTICS text_var1 = MESSAGE_TEXT, > > text_var2 = PG_EXCEPTION_DETAIL, > > text_var3 = PG_EXCEPTION_HINT; > > end; > > end loop; > > > > end if; > > return null; > > END; > > $$ LANGUAGE remove_prepared; > > > > E se for o caso de uma "prepared transaction" ser longa mesmo?? Claro > que isso não é bom, mas dependendo de como foi implementada a aplicação. > > Eu faria o seguinte: > > 1) Monitorar os pg_prepared_xacts > que X tempo, e dependendo do caso > tomar uma ação. Automatizar isso pode causar problemas. > > 2) Investigar porque a aplicação está deixando esses rastros para > corrigir eventuais distorções e analisar se realmente é necessário > utilizar 2pc (two-phase commit). > > PS: eu já passei por cenários em que se encaixam no item 2 e que na real > a arquitetura da app foi projetada para usar 2pc por desconhecimento de > como o PostgreSQL funciona (cluster, bancos, schemas, etc). > > > Att, > > -- > Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ > PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Atenciosamente Francisco Porfirio Ribeiro Neto
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
