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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a