Senhores,
Agora estou em duvida!
Sempre usei...
ALTER Role usuario
CREATEROLE;
... pra fazer com que um usuário comum tivesse permissão de criar outro
usuário, e assim realmente funciona. Quer dizer que esse usuário passa a ser
superusuário?
Renato
Senda
De: [EMAIL PROTECTED]
2008/8/14 Renato [EMAIL PROTECTED]
Senhores,
Agora estou em duvida!
Sempre usei...
ALTER Role usuario
CREATEROLE;
... pra fazer com que um usuário comum tivesse permissão de criar outro
usuário, e assim realmente funciona. Quer dizer que esse usuário passa a
ser
superusuário?
Nada
Pois é Ribamar.
Estou começando agora no Postgres, mas sou desenvolvedor há muito tempo.
Você deve lembrar que a atribuição de criar usuário é muito importante e
somente alguém de sua inteira confiança deve ter. Acho que foi isso que a
equipe pensou ou algo do gênero.
Concordo com você
Obrigado pessoal pelas respostas,
vou dar uma boa lida nesses documentos e depois posto aqui o resultado.
Obrigado mesmo!
Lucas.
2008/8/13 Roberto Mello [EMAIL PROTECTED]
2008/8/13 Lucas Mocellin [EMAIL PROTECTED]:
Como é uma migração de um banco que o pessoal usa windows, não estou
O jeito é não dar atributo createuser pra ninguém, já que o banco entende
como superuser.
Aí a aplicação que controlará isso. É uma pena!
Valeu, Ribamar.
At.te,
Alisson Viegas
[EMAIL PROTECTED]
---
Acsiv Sistemas
http://www.acsiv.com.br/ www.acsiv.com.br
De: [EMAIL PROTECTED]
Consegui criar o banco em LATIN1,
porém agora a briga é para importar os dados, vejam:
ERROR: relation cidade does not exist
ERROR: relation cidade does not exist
ERROR: relation cidade does not exist
ERROR: relation cidade does not exist
ERROR: relation cidade does not exist
ERROR:
Amigos,
Tenho 2 clientes que rodam o postgreSQL 8.2.x e que o postgresql.conf estava
programado para autovacuum = on
Ao passar do tempo o banco de dados foi enxendo e ficando lento, chegando
até a travar quando se acessava uma determinada tabela
Eu retirei o autovacuum = on e passei para = off
Alisson Viegas | Acsiv Sistemas escreveu:
O jeito é não dar atributo createuser pra ninguém, já que o banco
entende como superuser.
Aí a aplicação que controlará isso. É uma pena!
Uma possível solução é criar - como superusuário - uma função, com a
opção SECURITY DEFINER [1], que crie
2008/8/14 cardosodario [EMAIL PROTECTED]
Amigos,
Tenho 2 clientes que rodam o postgreSQL 8.2.x e que o postgresql.conf
estava
programado para autovacuum = on
Ao passar do tempo o banco de dados foi enxendo e ficando lento, chegando
até a travar quando se acessava uma determinada tabela
O que há de errado com essa função:
CREATE OR REPLACE FUNCTION buscar_pessoa(text)
RETURNS SETOF tb_pessoa AS
$BODY$
declare
texto text;
linha tb_pessoa%ROWTYPE;
begin
texto = replace(replace(ltrim(rtrim($1)), '', ''), '', '');
for linha in
select nomecompleto from tb_pessoa
Boa, Oswaldo.
Vou tentar aqui.
Valeu!
At.te,
Alisson Viegas
[EMAIL PROTECTED]
---
Acsiv Sistemas
www.acsiv.com.br
-Mensagem original-
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Em nome de Osvaldo
Rosario Kussama
Enviada em: quinta-feira, 14 de agosto de 2008 12:28
Para:
Daniel P Lim escreveu:
O que há de errado com essa função:
CREATE OR REPLACE FUNCTION buscar_pessoa(text)
RETURNS SETOF tb_pessoa AS
$BODY$
declare
texto text;
linha tb_pessoa%ROWTYPE;
begin
texto = replace(replace(ltrim(rtrim($1)), '', ''), '', '');
for linha in
select
Boa tarde. Estávamos fazendo um pg_restore e nesse momento caiu a energia,
quando retornou o sistema, o banco postgresql não entrou no ar, olhando o log,
ele dizia o que segue abaixo:
Postgresql 8.01 SO Linux
FATAL: arquivo de bloqueio postmaster.pid já existe
DICA: Outro postmaster (PID 3484)
2008/8/14 Arivaldo Bento [EMAIL PROTECTED]
Boa tarde. Estávamos fazendo um pg_restore e nesse momento caiu a energia,
quando retornou o sistema, o banco postgresql não entrou no ar, olhando o
log, ele dizia o que segue abaixo:
Postgresql 8.01 SO Linux
FATAL: arquivo de bloqueio
Desculpe, me expressei errado este arquivo já não existe e mesmo assim dá o
erro.
- Mensagem original
De: Ribamar Sousa [EMAIL PROTECTED]
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Quinta-feira, 14 de Agosto de 2008 13:52:11
Assunto: Re:
Pessoal,
acho que coloquei no tópico errado esse assunto, então aqui vai,
vejo que são vários erros randômicos
ERROR: could not access file $libdir/liblwgeom.dll: No such file or
directory
ERROR: function public.estimated_extent(text, text, text) does not exist
ERROR: could not access file
2008/8/14 Arivaldo Bento [EMAIL PROTECTED]
Desculpe, me expressei errado este arquivo já não existe e mesmo assim dá o
erro.
Já checou com ps ax|grep postgres para ver se tem algum processo?
Boa tarde. Estávamos fazendo um pg_restore e nesse momento caiu a energia,
quando retornou o
Mas então o recurso de autovacuum não eh interessante se ele trava a tabela,
ou no 8.3 ele não age assim?
Dario
cardosodario wrote:
Amigos,
Tenho 2 clientes que rodam o postgreSQL 8.2.x e que o postgresql.conf
estava programado para autovacuum = on
Ao passar do tempo o banco de dados
Pessoal,
nao sei se paralelismo de processos seria o titulo correto para esse assunto,
mas estou com a seguinte duvida.
Gostaria de saber se é possivel dividir um processo pesado (backup,
dump,vacuum, etc...) e varios processos trabalhando em paralelo?
exemplo tem 8 processadores ai na
Sim.
- Mensagem original
De: Ribamar Sousa [EMAIL PROTECTED]
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Quinta-feira, 14 de Agosto de 2008 14:23:10
Assunto: Re: [pgbr-geral] Res: Queda de Energia
2008/8/14 Arivaldo Bento [EMAIL PROTECTED]
Já havia verificado tb e não existem tais arquivos.
Obigrado.
- Mensagem original
De: Marcelo Costa [EMAIL PROTECTED]
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Quinta-feira, 14 de Agosto de 2008 14:15:21
Assunto: Re: [pgbr-geral] Queda de
2008/8/14 Arivaldo Bento [EMAIL PROTECTED]
Já havia verificado tb e não existem tais arquivos.
Obigrado.
O que o log te diz ?
--
Marcelo Costa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
Segue
Sucesso. Você pode iniciar o servidor de banco de dados utilizando:
/usr/bin/postmaster -D /var/lib/pgsql/data
ou
/usr/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start
LOG: desligando logger
LOG: desligando logger
LOG: desligando logger
FATAL: arquivo de bloqueio
já tentou dar um updatedb e um locate postmaster para ver se não está em
algum outro local?
Evandro
Arivaldo Bento wrote:
Segue
Sucesso. Você pode iniciar o servidor de banco de dados utilizando:
/usr/bin/postmaster -D /var/lib/pgsql/data
ou
/usr/bin/pg_ctl -D
Certamente o postmaster.pid ainda existe, tente localiza-lo.
2008/8/14 Arivaldo Bento [EMAIL PROTECTED]
Segue
Sucesso. Você pode iniciar o servidor de banco de dados utilizando:
/usr/bin/postmaster -D /var/lib/pgsql/data
ou
/usr/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start
On Thu, Aug 14, 2008 at 11:44 AM, Mr J.L. [EMAIL PROTECTED] wrote:
Gostaria de saber se é possivel dividir um processo pesado (backup,
dump,vacuum, etc...) e varios processos trabalhando em paralelo?
Rode os aplicativos em processos diferentes em paralelo, e.g. um
pg_dump de cada um dos seus
Ops, faltou um pequeno detalhe: isso só ocorre quando você usa:
vacuum full;
2008/8/14 cardosodario [EMAIL PROTECTED]
Mas então o recurso de autovacuum não eh interessante se ele trava a
tabela,
ou no 8.3 ele não age assim?
Dario
cardosodario wrote:
Amigos,
Tenho 2 clientes que
o pg_restore não recupera arquivos no formato texto-puro, tenta passar o
parametro -Ft e salva como tar ou tenta recuperar direto com psql se a base
não for muito grande, acho que vai resolver.
1 - pg_dump -i -h x.x.x.x -Ft c -v -f /tmp/web.tar
ou tenta psql -d cotesa_web -f caminho do arquivo
2008/8/14 flavio cardoso [EMAIL PROTECTED]:
o pg_restore não recupera arquivos no formato texto-puro, tenta passar o
parametro -Ft e salva como tar ou tenta recuperar direto com psql se a base
não for muito grande, acho que vai resolver.
Eu prefiro sempre usar o formato custom (-Fc), que da'
Obrigado.
- Mensagem original
De: Marcelo Costa [EMAIL PROTECTED]
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Quinta-feira, 14 de Agosto de 2008 15:34:28
Assunto: Re: [pgbr-geral] Res: Res: Queda de Energia
Certamente o postmaster.pid ainda
ou como ~postmaster.pid, se é que isto é possível?
-Mensagem original-
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] nome de Evandro
Ricardo Silvestre
Enviada em: quinta-feira, 14 de agosto de 2008 15:34
Para: Comunidade PostgreSQL Brasileira
Assunto: Re: [pgbr-geral] Res: Res: Queda de
2008/8/12 Ribamar Sousa [EMAIL PROTECTED]:
http://www.linuxinsight.com/optimize_postgresql_database_size.html
Esse artigo e' bem antigo. Os testes foram feitos com o PostgreSQL
7.4.8 que e' anciao, e nao reflete o atual estado do PostgreSQL.
Roberto
--
http://blog.divisiblebyfour.org/
2008/8/14 Roberto Mello [EMAIL PROTECTED]
2008/8/12 Ribamar Sousa [EMAIL PROTECTED]:
http://www.linuxinsight.com/optimize_postgresql_database_size.html
Esse artigo e' bem antigo. Os testes foram feitos com o PostgreSQL
7.4.8 que e' anciao, e nao reflete o atual estado do PostgreSQL.
Ribamar Sousa escreveu:
Se eu permitir que um campo que é a chave estrangeira seja nulo estou
quabrando a integridade, pois em sendo nulo o relacionamento já é
permitido (quando somente deveria ser permitido se o campo da FK fosse
igual ao da PK da outra).
Você não está quebrando a
[EMAIL PROTECTED] escreveu:
Vejam o link abaixo, um comparativo que fiz entre 2 ambiente, que
utilizam diferentes indices. A base de dados é do benchmark dbt-2.
Qual deles seria, na opinião de vocês, de melhor de desempenho? O
ambiente/configuração 1 ou 2 e Porque?
Duas coisas que
Alisson Viegas | Acsiv Sistemas escreveu:
Pessoal,
Por que a cláusula CREATEUSER do ALTER USER define a conta como superuser?
Não deveriam ser coisas diferentes?
Para não perder a compatibilidade com o CREATE USER anterior a
implementação de roles no PostgreSQL. Desde a versão 8.1, o CREATE
Ribamar Sousa escreveu:
2008/8/14 cardosodario [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
Amigos,
Tenho 2 clientes que rodam o postgreSQL 8.2.x e que o
postgresql.conf estava
programado para autovacuum = on
Ao passar do tempo o banco de dados foi enxendo e
2008/8/14 Euler Taveira de Oliveira [EMAIL PROTECTED]
Ribamar Sousa escreveu:
Se eu permitir que um campo que é a chave estrangeira seja nulo estou
quabrando a integridade, pois em sendo nulo o relacionamento já é
permitido (quando somente deveria ser permitido se o campo da FK fosse
38 matches
Mail list logo