Em 27 de abril de 2017 17:26, Fabrízio de Royes Mello < fabri...@timbira.com.br> escreveu:
> > Em 26 de abril de 2017 23:54, Euler Taveira <eu...@timbira.com.br> > escreveu: > > > > Em 26 de abril de 2017 23:40, Patrick B <patrickbake...@gmail.com> > escreveu: > >> > >> > >> Se eu fizer um basebackup do meu servidor e restaurar num novo, também > funcionaria? > > > > Não. Você estará transportando o inchaço de um lugar para outro. Uma > possibilidade seria > > renomear a tabela atual, fazer CREATE TABLE foo AS SELECT a, b, NULL as > campobytea > > FROM bar (as restrições devem ser criadas também) e depois que tudo > estiver certo fazer > > um DROP TABLE na tabela original. Isso irá evitar o inchaço. > > > > Verdade.. posso também fazer deste jeito. > É uma alternativa, mas se o OP tem janela de manutenção e, *dependendo* do > modelo de dados, será mais fácil ele realizar o UPDATE que mencionou > seguido de um VACUUM FULL que irá reescrever todos datafiles. > > > É um sistema online com 30 mil usuários, ou seja, não tem como eu ter downtime. Eu entendo que não há como fazer isso sem ter um downtime, pois qualquer coisa que eu faça eu irei precisar de um exclusive lock naquela tabela e, o usuário, não consegue nem logar se não tiver acesso à ela. Mas de qualquer forma eu provavelmente irei escolher a opção do pg_dump. Pois para eu fazer tanto o vacuum full quanto o CREATE TABLE AS, irei precisar ter mais espaço em disco e pra isso vou ter que por o sistema 2x offline, uma para incluir mais espaço e outra para rodar os comandos. A tabela tem 4TB, complicando ainda mais minha vida. Obrigado! Patrick
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
