On 16-01-2017 23:25, Euler Taveira wrote: > On 16-01-2017 16:01, Jonas Teixeira de Freitas wrote: >> https://listas.postgresql.org.br/pipermail/pgbr-geral/2010-April/020556.html >> >> Para o antigo problema de sequence pular 32 registros *log_cnt, * alguém >> conseguiu alguma solução? >> > Além da discussão citada, também comentei em [1] e na -hackers houve uma > discussão [2] também. > > Em resumo, é aquilo que o Dutra havia comentado: sequências foram > projetadas para terem "buracos". O fato de haver esse "buraco" de até 32 > números, é um detalhe de implementação para otimizar a escrita no WAL. >
Exatamente... as Sequences no PostgreSQL foram projetadas para NUNCA conflitar e não seguir uma série sem falhas (sua necessidade de negócio). Então se sua necessidade de negócio é uma série sem falhas talvez o objeto SEQUENCE não seja o ideal. >> Alguma forma de conseguir controlar a sequence para evitar que ocorra >> esse salto de numeração. >> > Não tem como controlar esse número em tempo de compilação ou a partir da > configuração. A única maneira é alterar SEQ_LOG_VALS em sequence.c. > Pode até ser mas isso pode levar a problemas de performance, veja o comentário no código: 46 /* 47 * We don't want to log each fetching of a value from a sequence, 48 * so we pre-log a few fetches in advance. In the event of 49 * crash we can lose (skip over) as many values as we pre-logged. 50 */ 51 #define SEQ_LOG_VALS 32 Sem contar que será necessário gerar um "fork" do PostgreSQL e necessário empacotar e distribuir a sua versão do PostgreSQL com esse "pequeno" ajuste. Se me perguntar "dá pra fazer" eu responderei que sim, mas será que vale a pena? > Por fim, não parece o serviço de maneira inadequada (kill -9, -m > immediate, ...) que você não terá problemas com isso. > Com certeza... parar o serviço do PostgreSQL conforme o Euler descreveu vc terá esse comportamento anormal e também em casos de crash no servidor seja por qual motivo for. > Não, isso definitivamente não é um bug. > Exato, é um comportamento normal do PostgreSQL conforme demonstrei no post citado pelo Jonas. Existem algumas alternativas para implementar uma sequence "gapless" no PostgreSQL, veja: https://gist.github.com/fabriziomello/5cfff0541cd34e157ead545d815c2194 http://www.varlena.com/GeneralBits/130.php Entretanto existe um patch que está "parado" que tem a intenção de implementar o "Sequence Access Method" [1] onde uma implementação como extensão é justamente o "Gapless Sequence" que irá atender esses requisitos de negócio. Participei como revisor do código mas ainda tem alguns problemas de design e o mesmo não foi pra frente. Ainda não vi nada novo do autor para a versão 10. Att, [1] https://commitfest.postgresql.org/9/466/ -- 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
