Re: [pgbr-geral] Replicação postgres
On 02/10/2015 11:58 AM, Flavio Henrique Araque Gurgel wrote: On 02/10/2015 09:35 AM, Leandro wrote: Pessoal, utilizo a replicação sincrona do postgresql versão 9.2 e depois de um tempo em execução a mesma apresentou problemas na replica conforme logs abaixo: WARNING,01000,page 1186 of relation base/91198868/91199917 is uninitialized,xlog redo vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0 PANIC,XX000,WAL contains references to invalid pages,xlog redo vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0 sendo que o master da replicação parece estar tudo normal, alguem já passou por situação parecida? Qual a versão exata? É a última da série 9.2? Há um bug conhecido e, dependendo da sua versão, pode não estar corrigido. A ordem é: 1) atualize os binários do PostgreSQL para 9.2.10 (no seu caso) 2) refaça o escravo (novo pg_basebackup). Hoje as 9:50 começou este problema para mim, estou procurando uma alternativa também. Versão 9.3.6 Não é a mesma versão do outro colega. Mas refaça seu pg_basebackup e recrie o novo escravo. Embora sua versão esteja em dia, se o pg_basebackup foi feito com a versão bugada, o erro pode acontecer tardiamente. Isso eu não sabia, talvez seja essa minha situação então. 2015-02-10 09:58:04 BRST [4882]: [6-1] user=,db= WARNING: page 196 of relation base/26790/24953388 is uninitialized 2015-02-10 09:58:04 BRST [4882]: [7-1] user=,db= CONTEXT: xlog redo visible: rel 1663/26790/24953388; blk 196 2015-02-10 09:58:04 BRST [4882]: [8-1] user=,db= PANIC: WAL contains references to invalid pages 2015-02-10 09:58:04 BRST [4882]: [9-1] user=,db= CONTEXT: xlog redo visible: rel 1663/26790/24953388; blk 196 2015-02-10 09:58:04 BRST [4880]: [6-1] user=,db= LOG: startup process (PID 4882) was terminated by signal 6: Aborted 2015-02-10 09:58:04 BRST [4880]: [7-1] user=,db= LOG: terminating any other active server processes como posso verificar que objeto que está apresentando o problema? Outra pergunta, abra outro assunto, não sequestre. Você encontra todos os objetos na tabela pg_class, no seu caso filtre pelo relfilenode : SELECT relname FROM pg_class WHERE relfilenode = 24953388; A consulta vai te retornar o nome da tabela ou índice corrompido. []s Flavio Gurgel ___ 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] Replicação postgres
On 02/10/2015 12:08 PM, Flavio Henrique Araque Gurgel wrote: Fiz um backup da base no slave, e fiz uma copia do arquivo que apresentava erro, ou seja, copiei ele do master pro slave e dei start. A principio está funcionando... vou monitorar o mesmo, qualquer coisa também eu volto o bkp. Isso é um perigo enorme e você pode ter inconsistências no escravo. Refazer o escravo do zero é o mais seguro. Sim, mas por isso mesmo eu fiz um backup do escravo antes. Estou verificando a situação, já que esse escravo está distante e vai depender do link para refazer o mesmo, e também ele é a ultima da ultima instancia. Ele faz parte da redundancia de DC, e eu tenho mais um slave aqui. []s Flavio Gurgel ___ 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] PostgreSQL x ArcGIS
(...) No que diz respeito a versão do PostgreSQL e PostGIS não vemos problemas. Mas não entendemos o que levaria ao produto restringir o SO do SGBD em Windows, Red Hat e SUSE Enterprise se o servidor do SGBD não é compartilhado com o servidor do produto. E vocês têm razão. Atualmente temos diversos servidores PostgreSQL rodando no CentOS sem qualquer problema com diversas aplicações (produtos open source ou aplicações desenvolvidas internamente usando desde Java a .Net). Eu também, assim como muitos aqui na lista. As minhas perguntas para a comunidade são: 1) Alguém conhece (ou consegue imaginar) alguma justificativa técnica para que um produto estabeleça restrições na camada subjacente do SGBD (ou seja o SO)? Tecnicamente falando: *zero* As empresas que fazem isso (limitar S.O.) o fazem por motivos geralmente de suporte (por exemplo, ao telefone, um técnico diz pra mudar o parâmetro x no arquivo y do diretório z). No seu caso, CentOS e Redhat são idênticos nesse ponto. Aí, quando se fala em CentOS, vem a questão contrato: se houver um problema de desempenho, poderiam dizer que a culpa é sua por não usar um S.O. homologado. 2) Sendo o PostgreSQL um software livre, pode um software proprietário fazer este tipo de restrição? Tecnicamente isso significa que o fornecedor não merece confiança. Contratualmente, eles estão na média do mercado, ou seja, medíocres. Em geral é assim no mundo proprietário. Mas sim, podem, não tem nenhuma relação com licenças livres aí. E a licença do PostgreSQL é extremamente simples e não restritiva. Agradeço antecipadamente as colaborações. Desculpe a sinceridade. []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] PostgreSQL x ArcGIS
2015-02-10 15:48 GMT-02:00 veronica.san...@ibge.gov.br: Prezados, boa tarde Boa tarde! Mas não entendemos o que levaria ao produto restringir o SO do SGBD em Windows, Red Hat e SUSE Enterprise se o servidor do SGBD não é compartilhado com o servidor do produto. Comodidade do fornecedor do produto, em ter de lidar com menos variáveis de configuração. Atualmente temos diversos servidores PostgreSQL rodando no CentOS sem qualquer problema com diversas aplicações (produtos open source ou aplicações desenvolvidas internamente usando desde Java a .Net). Claro, ele é um /clone/ quase perfeito do Red Hat. E poderia usar Debian também, provavelmente com vantagens. 1) Alguém conhece (ou consegue imaginar) alguma justificativa técnica para que um produto estabeleça restrições na camada subjacente do SGBD (ou seja o SO)? Estritamente técnica, não. Só conveniência do fornecedor, mesmo. 2) Sendo o PostgreSQL um software livre, pode um software proprietário fazer este tipo de restrição? Não é restrição, e nada tem a ver com licenciamento. É só um provedor de serviços, impondo condições porque pode, quer e lhe convém. Ninguém é obrigado a usar ArcGIS; eu particularmente acho isso até burrice, dados os sistemas livres que há nesse mercado. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] PostgreSQL x ArcGIS
Prezados, boa tarde recebi a demanda de criação de um ambiente como SGBD PostgreSQL para operar como geodatabase das ferramentas ArcGis Server e ArcGis Desktop. Solicitamos a matriz de compatibilidade dos produtos através do serviço de suporte. Para o ArcGIS Desktop recebemos as seguintes referências: 10.2: http://resources.arcgis.com/en/help/system-requirements/10.2/index.html#/PostgreSQL_Database_Requirements/0151007500/ 10.3: http://desktop.arcgis.com/en/desktop/latest/get-started/system-requirements/database-requirements-postgresql.htm E esta outra para o ArcGIS Server: http://desktop.arcgis.com/en/desktop/latest/get-started/system-requirements/arcgis-server-system-requirements.htm No que diz respeito a versão do PostgreSQL e PostGIS não vemos problemas. Mas não entendemos o que levaria ao produto restringir o SO do SGBD em Windows, Red Hat e SUSE Enterprise se o servidor do SGBD não é compartilhado com o servidor do produto. Atualmente temos diversos servidores PostgreSQL rodando no CentOS sem qualquer problema com diversas aplicações (produtos open source ou aplicações desenvolvidas internamente usando desde Java a .Net). As minhas perguntas para a comunidade são: 1) Alguém conhece (ou consegue imaginar) alguma justificativa técnica para que um produto estabeleça restrições na camada subjacente do SGBD (ou seja o SO)? 2) Sendo o PostgreSQL um software livre, pode um software proprietário fazer este tipo de restrição? Agradeço antecipadamente as colaborações. Esta mensagem é reservada. Sua divulgação, distribuição, reprodução ou qualquer forma de uso é proibida e depende de prévia autorização desta Instituição. O remetente utiliza o correio eletrônico no exercício do seu trabalho ou em razão dele, eximindo esta Instituição de qualquer responsabilidade por utilização indevida. Se você recebeu esta mensagem por engano, favor eliminá-la imediatamente. This message is reserved. Its disclosure, distribution, reproduction, or any other form of use is prohibited and shall depend upon previous proper authorization. The sender uses electronic mail in the exercise of his/her work or by virtue thereof, and the Institution accepts no liability for its undue use. If you have received this e-mail by mistake, please delete it immediately.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tabelas não utilizadas
Por favor, não responda acima. Faça-o abaixo ou comentando, como farei aqui. Acho que que acabei não deixei mto claro Matheus, não sou tão corajoso assim :). Coragem é diretamente proporcional à complexidade e criticidade do banco em questão :) É que não posso usar essa tática de testar via rename, posso causar uma parada do sistema só por fazer isso, o pool do Java acaba se perdendo, já aconteceu isso recentemente com um drop column que foi enviado e não foi retirado do código, desandou a casa toda. Logo, remover as tabelas então é que você não vai fazer *mesmo*. Estávamos todos certamente nos dizendo a base desse cara não deve ser crítica ou deve ter um montão de tabelas temporárias que são sob pleno controle dele mas agora sabemos que não é seu caso. A idéia é justamente listas as tabelas que não possuem acessos, passar para os Devs, e executar primeiramente em ambiente sandbox onde são rodados testes de selenium e afins, para então só ai executar a quente em produção, onde teremos 100% de certeza que nada era utilizado. Excelente ideia. Informar os desenvolvedores e testar tudo num ambiente controlado é a melhor opção mesmo. Você agora tem o caminho das pedras! []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Replicação postgres
Pessoal, utilizo a replicação sincrona do postgresql versão 9.2 e depois de um tempo em execução a mesma apresentou problemas na replica conforme logs abaixo: WARNING,01000,page 1186 of relation base/91198868/91199917 is uninitialized,xlog redo vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0 PANIC,XX000,WAL contains references to invalid pages,xlog redo vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0 sendo que o master da replicação parece estar tudo normal, alguem já passou por situação parecida? como posso verificar que objeto que está apresentando o problema? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação postgres
On 02/10/2015 09:35 AM, Leandro wrote: Pessoal, utilizo a replicação sincrona do postgresql versão 9.2 e depois de um tempo em execução a mesma apresentou problemas na replica conforme logs abaixo: WARNING,01000,page 1186 of relation base/91198868/91199917 is uninitialized,xlog redo vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0 PANIC,XX000,WAL contains references to invalid pages,xlog redo vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0 sendo que o master da replicação parece estar tudo normal, alguem já passou por situação parecida? Qual a versão exata? É a última da série 9.2? Há um bug conhecido e, dependendo da sua versão, pode não estar corrigido. A ordem é: 1) atualize os binários do PostgreSQL para 9.2.10 (no seu caso) 2) refaça o escravo (novo pg_basebackup). Hoje as 9:50 começou este problema para mim, estou procurando uma alternativa também. Versão 9.3.6 Não é a mesma versão do outro colega. Mas refaça seu pg_basebackup e recrie o novo escravo. Embora sua versão esteja em dia, se o pg_basebackup foi feito com a versão bugada, o erro pode acontecer tardiamente. 2015-02-10 09:58:04 BRST [4882]: [6-1] user=,db= WARNING: page 196 of relation base/26790/24953388 is uninitialized 2015-02-10 09:58:04 BRST [4882]: [7-1] user=,db= CONTEXT: xlog redo visible: rel 1663/26790/24953388; blk 196 2015-02-10 09:58:04 BRST [4882]: [8-1] user=,db= PANIC: WAL contains references to invalid pages 2015-02-10 09:58:04 BRST [4882]: [9-1] user=,db= CONTEXT: xlog redo visible: rel 1663/26790/24953388; blk 196 2015-02-10 09:58:04 BRST [4880]: [6-1] user=,db= LOG: startup process (PID 4882) was terminated by signal 6: Aborted 2015-02-10 09:58:04 BRST [4880]: [7-1] user=,db= LOG: terminating any other active server processes como posso verificar que objeto que está apresentando o problema? Outra pergunta, abra outro assunto, não sequestre. Você encontra todos os objetos na tabela pg_class, no seu caso filtre pelo relfilenode : SELECT relname FROM pg_class WHERE relfilenode = 24953388; A consulta vai te retornar o nome da tabela ou índice corrompido. []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] PostgreSQL x ArcGIS
2015-02-10 16:14 GMT-02:00 George Silva georger.si...@gmail.com: Só acho improdutivo nós, em geral, ficar criticando a escolha que nem sempre é de quem está pedindo suporte. Certamente não é produtivo. Mas produtividade não é a única razão para fazer algo, às vezes é desabafo mesmo. Exatamente porque quem pede suporte não é culpado é que fico à vontade (talvez erroneamente) em dar nome aos bois. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL x ArcGIS
Como nosso amigo acima respondeu, é mais conveniência do fornecedor. Existem diferenças que você terá de levar em consideração devido a localização de pastas de cada SO, ferramentas de gerenciamento de pacotes, etc. Fora isso, tudo deve funcionar normalmente. Em parceria com Instituto Sócio Ambiental, configurei alguns servidores lá com ArcGIS, PostgreSQL, PostGIS, em CentOS - 0 problemas. Um único cuidado é quando precisar de suporte. Eles podem realmente te cortar e falar que você não está em ambiente homologado. É balela claro, mas o contrato foi feito e assinado pela instituição, ou seja eles podem negar o suporte. Assim, não seria radical em chamar o uso do ArcGIS de burrice, mas realmente existem opções. Mas imagino que essa escolha, estava fora do escopo de trabalho da nossa colega, portanto não convém censurar ela pelo acordo que a instituição dela fez. 2015-02-10 15:53 GMT-02:00 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: 2015-02-10 15:48 GMT-02:00 veronica.san...@ibge.gov.br: Prezados, boa tarde Boa tarde! Mas não entendemos o que levaria ao produto restringir o SO do SGBD em Windows, Red Hat e SUSE Enterprise se o servidor do SGBD não é compartilhado com o servidor do produto. Comodidade do fornecedor do produto, em ter de lidar com menos variáveis de configuração. Atualmente temos diversos servidores PostgreSQL rodando no CentOS sem qualquer problema com diversas aplicações (produtos open source ou aplicações desenvolvidas internamente usando desde Java a .Net). Claro, ele é um /clone/ quase perfeito do Red Hat. E poderia usar Debian também, provavelmente com vantagens. 1) Alguém conhece (ou consegue imaginar) alguma justificativa técnica para que um produto estabeleça restrições na camada subjacente do SGBD (ou seja o SO)? Estritamente técnica, não. Só conveniência do fornecedor, mesmo. 2) Sendo o PostgreSQL um software livre, pode um software proprietário fazer este tipo de restrição? Não é restrição, e nada tem a ver com licenciamento. É só um provedor de serviços, impondo condições porque pode, quer e lhe convém. Ninguém é obrigado a usar ArcGIS; eu particularmente acho isso até burrice, dados os sistemas livres que há nesse mercado. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- George R. C. Silva SIGMA Consultoria http://www.consultoriasigma.com.br/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL x ArcGIS
2015-02-10 16:06 GMT-02:00 George Silva georger.si...@gmail.com: Assim, não seria radical em chamar o uso do ArcGIS de burrice, mas realmente existem opções. Mas imagino que essa escolha, estava fora do escopo de trabalho da nossa colega, portanto não convém censurar ela pelo acordo que a instituição dela fez. Ninguém o fez. Ela só tem a situação nada invejável de ter de dar suporte; alguém mais tomou a decisão. Posso imaginar que haja circunstâncias atenuantes, mas hoje em dia decidir por um sistema proprietário está cada vez mais difícil de justificar. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL x ArcGIS
2015-02-10 15:53 GMT-02:00 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: Ninguém é obrigado a usar ArcGIS; eu particularmente acho isso até burrice, dados os sistemas livres que há nesse mercado. Mil perdões pela expressão grosseira, conto com vossa compreensão e tolerância. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Ponto por virgula
Galera, estou com um probleminha que parece ser de alguma configuração. Instalei o PG em um computador, e a casa decimal está . e em outro , chequei no SO que a configuração está correta, porem no meu sistema, só aceita o . Alguém sabe oque pode ser? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação postgres
On 02/10/2015 10:51 AM, Jean Pereira wrote: On 02/10/2015 09:35 AM, Leandro wrote: Pessoal, utilizo a replicação sincrona do postgresql versão 9.2 e depois de um tempo em execução a mesma apresentou problemas na replica conforme logs abaixo: WARNING,01000,page 1186 of relation base/91198868/91199917 is uninitialized,xlog redo vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0 PANIC,XX000,WAL contains references to invalid pages,xlog redo vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0 sendo que o master da replicação parece estar tudo normal, alguem já passou por situação parecida? Hoje as 9:50 começou este problema para mim, estou procurando uma alternativa também. Versão 9.3.6 2015-02-10 09:58:04 BRST [4882]: [6-1] user=,db= WARNING: page 196 of relation base/26790/24953388 is uninitialized 2015-02-10 09:58:04 BRST [4882]: [7-1] user=,db= CONTEXT: xlog redo visible: rel 1663/26790/24953388; blk 196 2015-02-10 09:58:04 BRST [4882]: [8-1] user=,db= PANIC: WAL contains references to invalid pages 2015-02-10 09:58:04 BRST [4882]: [9-1] user=,db= CONTEXT: xlog redo visible: rel 1663/26790/24953388; blk 196 2015-02-10 09:58:04 BRST [4880]: [6-1] user=,db= LOG: startup process (PID 4882) was terminated by signal 6: Aborted 2015-02-10 09:58:04 BRST [4880]: [7-1] user=,db= LOG: terminating any other active server processes Fiz um backup da base no slave, e fiz uma copia do arquivo que apresentava erro, ou seja, copiei ele do master pro slave e dei start. A principio está funcionando... vou monitorar o mesmo, qualquer coisa também eu volto o bkp. como posso verificar que objeto que está apresentando o problema? ___ 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] Replicação postgres
On 02/10/2015 09:35 AM, Leandro wrote: Pessoal, utilizo a replicação sincrona do postgresql versão 9.2 e depois de um tempo em execução a mesma apresentou problemas na replica conforme logs abaixo: WARNING,01000,page 1186 of relation base/91198868/91199917 is uninitialized,xlog redo vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0 PANIC,XX000,WAL contains references to invalid pages,xlog redo vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0 sendo que o master da replicação parece estar tudo normal, alguem já passou por situação parecida? Hoje as 9:50 começou este problema para mim, estou procurando uma alternativa também. Versão 9.3.6 2015-02-10 09:58:04 BRST [4882]: [6-1] user=,db= WARNING: page 196 of relation base/26790/24953388 is uninitialized 2015-02-10 09:58:04 BRST [4882]: [7-1] user=,db= CONTEXT: xlog redo visible: rel 1663/26790/24953388; blk 196 2015-02-10 09:58:04 BRST [4882]: [8-1] user=,db= PANIC: WAL contains references to invalid pages 2015-02-10 09:58:04 BRST [4882]: [9-1] user=,db= CONTEXT: xlog redo visible: rel 1663/26790/24953388; blk 196 2015-02-10 09:58:04 BRST [4880]: [6-1] user=,db= LOG: startup process (PID 4882) was terminated by signal 6: Aborted 2015-02-10 09:58:04 BRST [4880]: [7-1] user=,db= LOG: terminating any other active server processes como posso verificar que objeto que está apresentando o problema? ___ 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] Replicação postgres
Fiz um backup da base no slave, e fiz uma copia do arquivo que apresentava erro, ou seja, copiei ele do master pro slave e dei start. A principio está funcionando... vou monitorar o mesmo, qualquer coisa também eu volto o bkp. Isso é um perigo enorme e você pode ter inconsistências no escravo. Refazer o escravo do zero é o mais seguro. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
