On 25-08-2015 18:26, Everton Berz wrote: > Fabrízio > > acredito que só aconteça quando as outras propriedades (não toast) > estejam setadas. Veja se consegue reproduzir os comandos abaixo. > > Entretanto percebi agora que quando fiz na tabela zerada, apesar de não > emitir erro, o parâmetro não é setado efetivamente. > Fica a dúvida de como na nossa tabela antiga aquele parâmetro foi > injetado. Pode ter acontecido durante algum pg_upgrate ou algo do tipo. > > > [root@xxx04-bug-db ~]# psql -U postgres everton_destino > psql (9.3.5) > Digite "help" para ajuda. > > everton_destino=# select version(); > version > -------------------------------------------------------------------------------------------------------------- > PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) > 4.4.7 20120313 (Red Hat 4.4.7-4), 64-bit > (1 registro) > > everton_destino=# CREATE TABLE tb_hash_session ( > everton_destino(# id_hash_session integer NOT NULL, > everton_destino(# id_pessoa integer NOT NULL, > everton_destino(# ds_hash character varying(40) NOT NULL, > everton_destino(# dt_expiracao timestamp without time zone NOT NULL, > everton_destino(# ds_ip character varying(40) NOT NULL > everton_destino(# ) > everton_destino-# WITH ( > everton_destino(# autovacuum_enabled=true, > autovacuum_analyze_scale_factor=0.001, autovacuum_analyze_threshold=1, > everton_destino(# autovacuum_vacuum_scale_factor=0.003, > autovacuum_vacuum_threshold=3, autovacuum_vacuum_cost_delay=3 > everton_destino(# ); > CREATE TABLE > > everton_destino=# alter table tb_hash_session set > (toast.autovacuum_analyze_scale_factor=0.001); > ALTER TABLE > > ( ^ deveria ter dado erro, certo? Talvez isso possa ser reportado como > bug. ) >
Na verdade é um comportamento normal até o momento, ele não gera uma exceção mas também não efetiva a operação alterando a "pg_class.reloptions". Há algum tempo implementamos a exceção para o ALTER TABLE RESET que também não "alertava" [1]. Vou reportar lá e propor um patch para gerar uma exceção nesse caso. Creio que não irão rejeitar. > everton_destino=# \d+ tb_hash_session > Tabela "public.tb_hash_session" > Coluna | Tipo | Modificadores | > Armazenamento | Estat¦sticas | Descri¦¦o > -----------------+-----------------------------+---------------+---------------+--------------+----------- > id_hash_session | integer | n¦o nulo | plain > | | > id_pessoa | integer | n¦o nulo | plain > | | > ds_hash | character varying(40) | n¦o nulo | > extended | | > dt_expiracao | timestamp without time zone | n¦o nulo | plain > | | > ds_ip | character varying(40) | n¦o nulo | > extended | | > T¦m OIDs: n¦o > Op¦¦es: autovacuum_enabled=true, autovacuum_analyze_scale_factor=0.001, > autovacuum_analyze_threshold=1, autovacuum_vacuum_scale_factor=0.003, > autovacuum_vacuum_threshold=3, autovacuum_vacuum_cost_delay=3 > > Entretanto o parâmetro não está aplicado, conferir na > pg_class.reloptions e também não é exibido. > Por esse motivo não é "bem um bug"... Att, [1] http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=73d78e11a0f7183c80b93eefbbb6026fe9664015 -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
signature.asc
Description: OpenPGP digital signature
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
