Hum, muito interessante :)
2010/12/18 Marcal Hokama <[email protected]> > > > ________________________________ > > From: [email protected] > > To: [email protected] > > Date: Tue, 14 Dec 2010 15:22:20 -0200 > > Subject: [pgbr-geral] Alterar tabela Aberta > > > > Pessoal não vou fazer comparações aqui heim, é só pra saber se posso ou > > não posso. > > No MySQL eu posso alterar uma tabela mesmo que esteja sendo usada, é > > claro que não vou fazer alterações críticas como deletar uma coluna ou > > mudar o nome ou tipo de um campo, mas adicionar um campo. > > Por exemplo: > > > > ALTER TABLE vendas_recebe ADD COLUMN taxa_ban numeric(12,2) NOT NULL > > DEFAULT 0; > > > > Estou adicionando uma coluna que nao pode ser nula, mas com valor > > padrao dessa forma não pode dar erro. > > > > No MySQL não importa se estão usando o sistema. > > > > Na verdade, no MySQL a tabela que está sendo alterada ainda pode ser > utilizada somente para leitura por outras sessões, e as escritas podem > sofrer "atraso", conforme [1]: > > "in most cases, ALTER TABLE makes a temporary copy of the original table. > MySQL incorporates the alteration into the copy, then deletes the original > table and renames the new one. While ALTER TABLE is executing, the original > table is readable by other sessions. Updates and writes to the table are > stalled until the new table is ready, and then are automatically redirected > to the new table without any failed updates. The temporary table is created > in the database directory of the new table. This can differ from the > database directory of the original table for ALTER TABLE operations that > rename the table to a different database." > > > Mas no Postgres percebi que ele congela o PgAdmin até que a tabela seja > > totalmente liberada... imagino que seja porque o PgAdmin precise de > > acesso exclusivo a tal tabela quando vai fazer alguma alteração. > > > > Pergunta: Existe como "burlar" isso? > > > > Ou seja quando eu tiver certeza de que minha alteração não causará > > problema eu force a alteração? > > > > A princípio não, conforme [2]: > > "ALTER TABLE cannot safely be executed concurrently with other operations > on the same table, so it obtains an exclusive lock on the table to enforce > that. > (...) > ACCESS EXCLUSIVE - Conflicts with locks of all modes (ACCESS SHARE, ROW > SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW > EXCLUSIVE,EXCLUSIVE, and ACCESS EXCLUSIVE). This mode guarantees that the > holder is the only transaction accessing the table in any way.Acquired by > the ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER, and VACUUM FULL > commands. This is also the default lock mode for LOCK TABLE statements that > do not specify a mode explicitly. > Tip: Only an ACCESS EXCLUSIVE lock blocks a SELECT (without FOR > UPDATE/SHARE) statement." > > Marcelo Silva > > > > [1] http://dev.mysql.com/doc/refman/5.1/en/alter-table.html[2] > http://www.postgresql.org/docs/current/static/explicit-locking.html > > Atenciosamente, > > Marçal de Lima Hokama----------------------------e-mail: mhokama > @hotmail.comhttp://www.twitter.com/mhokama > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
