Re: [pgbr-geral] REF: RETORNO DE SALDO - WINDOW FUNCTION
Olá Pessoal, Tenho duas tabelas: Tabela Saldos das Contas e Tabela Saidas. EX: TABELA SALDOS: CONTA|SALDO 200 | 200.00 201 | 500.00 Tenho o seguinte sentença que me retorna a soma das contas, como segue: SELECT row_number() OVER(PART BY conta ORDER BY conta,valor), setor, valor, conta, SUM(valor) OVER(PART BY conta ORDER BY conta,valor) as Total FROM saidas ORDER BY conta. RETORNO: 1-1-200-50.00-50.00 2-1-200-60.00-110.00 3-1-200-50.00-160.00 1-1-201-80.00-80.00 2-1-201-40.00-120.00 3-1-201-30.00-150.00 Preciso buscar o saldo de cada conta da tabela saldos para ficar assim: SALDO 200.00 1-1-200-50.00-250.00 2-1-200-60.00-310.00 3-1-200-50.00-360.00 SALDO 500.00 1-1-201-80.00-580.00 2-1-201-40.00-620.00 3-1-201-30.00-650.00 Alguem pode dar uma dica ? CTE com RECURSIVE : http://www.postgresql.org/docs/current/static/queries-with.html []s Flavio ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Failback em replicação nativa PostgreSQL 9.3
2014-09-04 22:06 GMT-03:00 Danilo Silva : > Então não tem jeito mesmo, tem que ser feito, no meu caso, o > pg_basebackup novamente. > > Perguntei isso porque o processo do pg_basebackup leva quase 2 horas... > Imaginando nas possíveis transações que podem ocorrer nesse período, o > parâmetro wal_keep_segments pode me ajudar a não *perder* essas transações > durante o processo, correto? > O problema é que no momento da queda pode acontecer do servidor primário estar um pouco a frente do secundário, daí como o você promoveu o secundário, eles estão em pontos diferentes e não há como mais fazer o antigo-primário seguir o novo. E nesse caso o wal_keep_segments não vai te ajudar em nada. Logo, a melhor e mais confiável solução é mesmo fazer um backup base novamente. Uma ferramenta que talvez ajude é a pg_rewind [1], mas admito que nunca a usei (achei arriscado demais). Ela foi feita para voltar um secundário à sincronia com o primário após o primeiro ter sido promovido. Não sei dizer ao certo se ela também pode fazer o contrário. De qualquer forma, no caso de failback, eu não acho que 2 horas seja um valor alto. Afinal, um failover não é algo que deve acontecer com frequência. [1] https://github.com/vmware/pg_rewind Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Failback em replicação nativa PostgreSQL 9.3
Então não tem jeito mesmo, tem que ser feito, no meu caso, o pg_basebackup novamente. Perguntei isso porque o processo do pg_basebackup leva quase 2 horas... Imaginando nas possíveis transações que podem ocorrer nesse período, o parâmetro wal_keep_segments pode me ajudar a não *perder* essas transações durante o processo, correto? O problema é que no momento da queda pode acontecer do servidor primário estar um pouco a frente do secundário, daí como o você promoveu o secundário, eles estão em pontos diferentes e não há como mais fazer o antigo-primário seguir o novo. E nesse caso o wal_keep_segments não vai te ajudar em nada. Logo, a melhor e mais confiável solução é mesmo fazer um backup base novamente. Uma ferramenta que talvez ajude é a pg_rewind [1], mas admito que nunca a usei (achei arriscado demais). Ela foi feita para voltar um secundário à sincronia com o primário após o primeiro ter sido promovido. Não sei dizer ao certo se ela também pode fazer o contrário. De qualquer forma, no caso de failback, eu não acho que 2 horas seja um valor alto. Afinal, um failover não é algo que deve acontecer com frequência. [1] https://github.com/vmware/pg_rewind Essa ferramenta pode ser uma dádiva do failback e bastante discussão foi colocada em cima dela. Como ela está sendo desenvolvida em cima do 9.4, tudo é muito beta ainda, tanto o PostgreSQL quanto a própria ferramenta, mas acho que ela tem tudo para emplacar e entrar na árvore contrib oficial em uma ou duas versões. Num banco de dados de vários gigabytes, aplicar as modificações a partir do WAL é algo bastante interessante para recolocar rapidamente as coisas em estado de alta disponibilidade novamente. Note que a ferramenta exige que a nova funcionalidade de checksums esteja habilitada ou wal_hint_bits, logo, a restauração deve ser bastante segura em termos de confiabilidade. Testemos! []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] REF: RETORNO DE SALDO - WINDOW FUNCTION
2014-09-04 23:21 GMT-03:00 Paulo Pereira : > Tenho duas tabelas: Tabela Saldos das Contas e Tabela Saidas. EX: > TABELA SALDOS: > CONTA|SALDO > 200 | 200.00 > 201 | 500.00 > > Tenho o seguinte sentença que me retorna a soma das contas, como segue: > SELECT row_number() OVER(PART BY conta ORDER BY conta,valor), > setor, > valor, > conta, > SUM(valor) OVER(PART BY conta ORDER BY conta,valor) as Total > FROM saidas > ORDER BY conta. > > RETORNO: > 1-1-200-50.00-50.00 > 2-1-200-60.00-110.00 > 3-1-200-50.00-160.00 > 1-1-201-80.00-80.00 > 2-1-201-40.00-120.00 > 3-1-201-30.00-150.00 > > Preciso buscar o saldo de cada conta da tabela saldos para ficar assim: > SALDO 200.00 > 1-1-200-50.00-250.00 > 2-1-200-60.00-310.00 > 3-1-200-50.00-360.00 > SALDO 500.00 > 1-1-201-80.00-580.00 > 2-1-201-40.00-620.00 > 3-1-201-30.00-650.00 > > Alguem pode dar uma dica ? > Eu faria usando UNION ALL, da seguinte forma: SELECT 1 AS tipo, NULL::bigint, NULL::integer AS setor, NULL::numeric AS valor, conta, saldo AS Total FROM saldo UNION ALL SELECT 2 AS tipo, row_number() OVER(PARTITION BY conta ORDER BY valor), setor, valor, conta, SUM(valor) OVER(PARTITION BY conta ORDER BY valor) as Total FROM saidas ORDER BY conta, tipo, valor Assim, na aplicação você só itera os registros (que já virão ordenados), quando tipo for 1 é "saldo", quando tipo for 2 é "conta". Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] REF: RETORNO DE SALDO - WINDOW FUNCTION
Outra sugestão ... http://emersonhermann.blogspot.com.br/2013/01/desenvolvendo-querys-sql-para-razao-e.html http://www.emersonhermann.blogspot.com.br/2012/09/consulta-sql-de-plano-de-contas-query.html Em 5 de setembro de 2014 09:24, Matheus de Oliveira < matioli.math...@gmail.com> escreveu: > > 2014-09-04 23:21 GMT-03:00 Paulo Pereira : > > Tenho duas tabelas: Tabela Saldos das Contas e Tabela Saidas. EX: >> TABELA SALDOS: >> CONTA|SALDO >> 200 | 200.00 >> 201 | 500.00 >> >> Tenho o seguinte sentença que me retorna a soma das contas, como segue: >> SELECT row_number() OVER(PART BY conta ORDER BY conta,valor), >> setor, >> valor, >> conta, >> SUM(valor) OVER(PART BY conta ORDER BY conta,valor) as Total >> FROM saidas >> ORDER BY conta. >> >> RETORNO: >> 1-1-200-50.00-50.00 >> 2-1-200-60.00-110.00 >> 3-1-200-50.00-160.00 >> 1-1-201-80.00-80.00 >> 2-1-201-40.00-120.00 >> 3-1-201-30.00-150.00 >> >> Preciso buscar o saldo de cada conta da tabela saldos para ficar assim: >> SALDO 200.00 >> 1-1-200-50.00-250.00 >> 2-1-200-60.00-310.00 >> 3-1-200-50.00-360.00 >> SALDO 500.00 >> 1-1-201-80.00-580.00 >> 2-1-201-40.00-620.00 >> 3-1-201-30.00-650.00 >> >> Alguem pode dar uma dica ? >> > > > Eu faria usando UNION ALL, da seguinte forma: > > SELECT 1 AS tipo, > NULL::bigint, > NULL::integer AS setor, > NULL::numeric AS valor, > conta, > saldo AS Total > FROM saldo > UNION ALL > SELECT 2 AS tipo, > row_number() OVER(PARTITION BY conta ORDER BY valor), > setor, > valor, > conta, > SUM(valor) OVER(PARTITION BY conta ORDER BY valor) as Total > FROM saidas > ORDER BY conta, tipo, valor > > Assim, na aplicação você só itera os registros (que já virão ordenados), > quando tipo for 1 é "saldo", quando tipo for 2 é "conta". > > Atenciosamente, > -- > Matheus de Oliveira > Analista de Banco de Dados > Dextra Sistemas - MPS.Br nível F! > www.dextra.com.br/postgres > > > ___ > 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] FATAL: terminando conexão por causa de um conflito com recuperação
Pessoal bom dia, Tenho um ambiente replicado com a replicação nativa do postgres, onde no slave para dividir a carga nas consultas apontei alguns sistemas que só fazem selects (nada de inserts, updates). Agora no log do Slave está aparecendo as seguintes mensagens: 2014-09-05 09:48:11 BRT [12271]: [1-1] user=postgres,db=base FATAL: terminando conexão por causa de um conflito com recuperação 2014-09-05 09:48:11 BRT [12271]: [2-1] user=postgres,db=base DETALHE: Consulta do usuário pode ter precisado acessar versões de registros que devem ser removidas. 2014-09-05 09:48:11 BRT [12271]: [3-1] user=postgres,db=base DICA: Dentro de instantes você poderá conectar novamente ao banco de dados e repetir seu commando. 2014-09-05 09:48:11 BRT [12286]: [8-1] user=postgres,db=base ERRO: cancelando comando por causa de um conflito com recuperação 2014-09-05 09:48:11 BRT [12286]: [9-1] user=postgres,db=base DETALHE: Consulta do usuário pode ter precisado acessar versões de registros que devem ser removidas. Fiz uma procura rapida no google, mas não tive muito sucesso. Vocês já passaram por isto alguma vez? -- José Ariel Ferreira Alves arielalves...@gmail.com ariel.al...@msn.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] FATAL: terminando conexão por causa de um conflito com recuperação
Pessoal bom dia, Tenho um ambiente replicado com a replicação nativa do postgres, onde no slave para dividir a carga nas consultas apontei alguns sistemas que só fazem selects (nada de inserts, updates). Agora no log do Slave está aparecendo as seguintes mensagens: 2014-09-05 09:48:11 BRT [12271]: [1-1] user=postgres,db=base FATAL: terminando conexão por causa de um conflito com recuperação 2014-09-05 09:48:11 BRT [12271]: [2-1] user=postgres,db=base DETALHE: Consulta do usuário pode ter precisado acessar versões de registros que devem ser removidas. 2014-09-05 09:48:11 BRT [12271]: [3-1] user=postgres,db=base DICA: Dentro de instantes você poderá conectar novamente ao banco de dados e repetir seu commando. 2014-09-05 09:48:11 BRT [12286]: [8-1] user=postgres,db=base ERRO: cancelando comando por causa de um conflito com recuperação 2014-09-05 09:48:11 BRT [12286]: [9-1] user=postgres,db=base DETALHE: Consulta do usuário pode ter precisado acessar versões de registros que devem ser removidas. Fiz uma procura rapida no google, mas não tive muito sucesso. Vocês já passaram por isto alguma vez? Você não disse a versão. Isso ocorre porque uma tupla não necessária ao mestre e que foi removida por uma passagem do autovacuum é necessária à consulta no escravo. Para evitar isso, ligar a configuração "hot_standby_feedback" no escravo. Isso está disponível a partir da versão 9.1. Na versão 9.0 existem algumas estratégias possíveis. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] FATAL: terminando conexão por causa de um conflito com recuperação
Obrigado Flavio, Desculpa, a versão é a 9.1.14. Fiz o ajuste em "hot_standby_feedback", agora é só acompanhar. Segue a configuração de replicação do Escravo da maneira que deixei. # - Master Server - # These settings are ignored on a standby server #max_wal_senders = 0# max number of walsender processes # (change requires restart) #wal_sender_delay = 1s # walsender cycle time, 1-1 milliseconds #wal_keep_segments = 0 # in logfile segments, 16MB each; 0 disables #vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed #replication_timeout = 60s # in milliseconds; 0 disables #synchronous_standby_names = '' # standby servers that provide sync rep # comma-separated list of application_name # from standby(s); '*' = all # - Standby Servers - # These settings are ignored on a master server hot_standby = on# "on" allows queries during recovery # (change requires restart) #max_standby_archive_delay = 30s# max delay before canceling queries # when reading WAL from archive; # -1 allows indefinite delay #max_standby_streaming_delay = 30s # max delay before canceling queries # when reading streaming WAL; # -1 allows indefinite delay #wal_receiver_status_interval = 10s # send replies at least this often # 0 disables hot_standby_feedback = on # send info from standby to prevent # query conflicts Em 5 de setembro de 2014 10:01, Flavio Henrique Araque Gurgel < fha...@gmail.com> escreveu: > Pessoal bom dia, >> >> >> Tenho um ambiente replicado com a replicação nativa do postgres, onde no >> slave para dividir a carga nas consultas apontei alguns sistemas que só >> fazem selects (nada de inserts, updates). >> >> Agora no log do Slave está aparecendo as seguintes mensagens: >> >> >> >> 2014-09-05 09:48:11 BRT [12271]: [1-1] user=postgres,db=base FATAL: >> terminando conexão por causa de um conflito com recuperação >> 2014-09-05 09:48:11 BRT [12271]: [2-1] user=postgres,db=base DETALHE: >> Consulta do usuário pode ter precisado acessar versões de registros >> que devem ser removidas. >> 2014-09-05 09:48:11 BRT [12271]: [3-1] user=postgres,db=base DICA: >> Dentro de instantes você poderá conectar novamente ao banco de dados e >> repetir seu commando. >> 2014-09-05 09:48:11 BRT [12286]: [8-1] user=postgres,db=base ERRO: >> cancelando comando por causa de um conflito com recuperação >> 2014-09-05 09:48:11 BRT [12286]: [9-1] user=postgres,db=base DETALHE: >> Consulta do usuário pode ter precisado acessar versões de registros >> que devem ser removidas. >> >> >> Fiz uma procura rapida no google, mas não tive muito sucesso. Vocês já >> passaram por isto alguma vez? >> > > Você não disse a versão. > Isso ocorre porque uma tupla não necessária ao mestre e que foi removida > por uma passagem do autovacuum é necessária à consulta no escravo. > Para evitar isso, ligar a configuração "hot_standby_feedback" no escravo. > Isso está disponível a partir da versão 9.1. Na versão 9.0 existem algumas > estratégias possíveis. > > []s > Flavio Gurgel > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- José Ariel Ferreira Alves arielalves...@gmail.com ariel.al...@msn.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] REF: RETORNO DE SALDO - WINDOW FUNCTION
Show de bola, muito bom mesmo, exatamente o que eu precisava. Obrigado Mateus e Emerson pelas preciosas dicas. Att, Paulo. 2014-09-04 23:21 GMT-03:00 Paulo Pereira : Tenho duas tabelas: Tabela Saldos das Contas e Tabela Saidas. EX: TABELA SALDOS: CONTA|SALDO 200 | 200.00 201 | 500.00 Tenho o seguinte sentença que me retorna a soma das contas, como segue: SELECT row_number() OVER(PART BY conta ORDER BY conta,valor), setor, valor, conta, SUM(valor) OVER(PART BY conta ORDER BY conta,valor) as Total FROM saidas ORDER BY conta. RETORNO: 1-1-200-50.00-50.00 2-1-200-60.00-110.00 3-1-200-50.00-160.00 1-1-201-80.00-80.00 2-1-201-40.00-120.00 3-1-201-30.00-150.00 Preciso buscar o saldo de cada conta da tabela saldos para ficar assim: SALDO 200.00 1-1-200-50.00-250.00 2-1-200-60.00-310.00 3-1-200-50.00-360.00 SALDO 500.00 1-1-201-80.00-580.00 2-1-201-40.00-620.00 3-1-201-30.00-650.00 Alguem pode dar uma dica ? Eu faria usando UNION ALL, da seguinte forma: SELECT 1 AS tipo, NULL::bigint, NULL::integer AS setor, NULL::numeric AS valor, conta, saldo AS Total FROM saldo UNION ALL SELECT 2 AS tipo, row_number() OVER(PARTITION BY conta ORDER BY valor), setor, valor, conta, SUM(valor) OVER(PARTITION BY conta ORDER BY valor) as Total FROM saidas ORDER BY conta, tipo, valor Assim, na aplicação você só itera os registros (que já virão ordenados), quando tipo for 1 é "saldo", quando tipo for 2 é "conta". ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
