On Wed, 23 Oct 2002, Tom Lane wrote:
> Dan Langille <[EMAIL PROTECTED]> writes:
> > Will I be able to give people the right to execute a function, but not
> > view it?
>
> Write it in C. Short of that, you're asking for unenforceable
> restrictions on the ability to read pg_proc.
I like that app
Dan Langille <[EMAIL PROTECTED]> writes:
> Will I be able to give people the right to execute a function, but not
> view it?
Write it in C. Short of that, you're asking for unenforceable
restrictions on the ability to read pg_proc.
regards, tom lane
-
On Tue, 22 Oct 2002, Bruno Wolff III wrote:
> In 7.3 you can get a pretty good handle on this. The database owner can
> restrict who can create schemas and schema owners can control who can
> create objects in that schema.
Will I be able to give people the right to execute a function, but not
vie
On Tue, Oct 22, 2002 at 21:01:59 +0200,
Gabor Faludi <[EMAIL PROTECTED]> wrote:
> I've been searching the web for a solution on this but no luck .
>
> I'm administering a webserver w/ PHP apps on . I had an idea to create an
> application database and give access to certain users to maintain the
On Tue, 2002-10-22 at 17:02, Tom Lane wrote:
> [EMAIL PROTECTED] (Jeff Boes) writes:
> > We have a few tables that seem to have suffered some kind of
> > corruption in their TOAST files. Symptoms include:
>
> > + Runaway CPU usage during VACUUM ANALYZE (load average
> >spikes of 20x normal
[EMAIL PROTECTED] (Jeff Boes) writes:
> We have a few tables that seem to have suffered some kind of
> corruption in their TOAST files. Symptoms include:
> + Runaway CPU usage during VACUUM ANALYZE (load average
>spikes of 20x normal for 10-15 minutes at a time) and
>more rarely during
We have a few tables that seem to have suffered some kind of
corruption in their TOAST files. Symptoms include:
+ Runaway CPU usage during VACUUM ANALYZE (load average
spikes of 20x normal for 10-15 minutes at a time) and
more rarely during other operations
+ Recurring messages of "ERRO
Jeff Self <[EMAIL PROTECTED]> writes:
> I'm trying to set my datestyle automatically in postgresql.conf this
> way:
> datestyle = 'iso, us'
That will work as of PG 7.3, but not in prior releases. (Datestyle and
a couple of other slightly-weird SET variables didn't get folded into
GUC until 7.3.)
I've been searching the web for a solution on this but no luck .
I'm administering a webserver w/ PHP apps on . I had an idea to create an
application database and give access to certain users to maintain the data
within the database tables , but also I'd like to make sure only certain
users are a
I'm trying to set my datestyle automatically in postgresql.conf this
way:
datestyle = 'iso, us'
But Postgresql won't start when I do this. I get the following message
in my logfile:
FATAL 1: 'datestyle' is not a valid option name
>From other examples of postgresql.conf I've looked at, this shoul
> Next your going to ask what will stop root
from stopping your> PostgreSQL, compiling a second copy with
authentication disabled and> using your data directory as it's source
:)
He he i'm enough paranoic :))
> If you want to prevent root from
accomplishing these things, you're> going to h
"Igor Georgiev" <[EMAIL PROTECTED]> writes:
> Ok, but my question actually isn't about pg_hba.conf comments, i read enough
> but what will stop root from adding this lines or doing su - postgres ??
As somebody already pointed out, you *must* trust the people with root
access to your machine; ther
I have just installed redhat 8.0. It comes with postgresql rpms for
7.2.2. I have been trying to get an
application I have written to work, but my queries fail whenever I have
queries that use internal
date/time formatting functions.
example:
SELECT a.assignmentid AS "id",
u.lastname || ', ' ||
> They can just read the raw database files as
well.
wow I'm not sure
how about this
edit pg_hba.conf
# Allow any user on the local system to connect to
any # database under any
username
local
all
trust
su -
On Tue, 22 Oct 2002, Igor Georgiev wrote:
> > > edit *pg_hba.conf *
> > > # Allow any user on the local system to connect to any
> > > # database under any username, but only via an IP connection:
> > > host all 127.0.0.1 255.255.255.255trust
>
Title: Gareth Stationery
Hey all!
I'm muddled up about
something.
I'm creating a new database, and absolute
paths are disallowed.
Therefore I su to postgres ( the owner of
the service ) and run the following:
export PGDATA2=/bla/bla/bla
initlocation PGDATA2
initloca
Title: Gareth Stationery
Quick response too:
Shortly after sending the email I tried
exactly what I said, with the following alteration:
I put the lines in the .bash_profile first,
then initlocation'd then I exited and restarted postgres,
then I su'd back in - and tried the create -
and bin
>
> edit *pg_hba.conf *>
> # Allow any user on the
local system to connect to any>
> # database under any
username, but only via an IP connection:>
>
host
all
127.0.0.1 255.255.255.255
trust >
> # The same, over
Unix-sock
Title: Gareth Stationery
Hey all!
I'm muddled up about something.
I'm creating a new database, and absolute
paths are disallowed.
Therefore I su to postgres ( the owner of
the service ) and run the following:
export PGDATA2=/bla/bla/bla
initlocation PGDATA2
initlocation returns fine - te
On Fri, Oct 18, 2002 at 09:44:46AM -0400, Tom Lane wrote:
> Will LaShell <[EMAIL PROTECTED]> writes:
> > Does anyone know why rserve doesn't support/use multi-field keys for the
> > replication id?
>
> Well, the one in contrib/ is only a prototype. The version that
> PostgreSQL Inc sells commerci
On Thu, Oct 10, 2002 at 09:46:14AM +0200, Reiner Dassing wrote:
> Hello all!
>
> I would like to ask what would be the best procedure to upgrade to a
> new version of PostgreSQL in a production system when there is a 'initdb'
> necessary?
>
> Situation:
> We are running PostgreSQL in a productio
On Tue, Oct 22, 2002 at 17:05:38 +0200,
Igor Georgiev <[EMAIL PROTECTED]> wrote:
> Is there any way to prevent superuser to acces the database ?
> I mean something like "GRANT / REVOKE CONNECT" MECHANISM
>
> I have no idea how to prevent root from access data in one of this ways :
> root @ l
edit *pg_hba.conf *
# Allow any user on the local system to connect to any
# database under any username, but only via an IP connection:
host all 127.0.0.1 255.255.255.255trust
# The same, over Unix-socket connections:
local
"Stein, Jochen" <[EMAIL PROTECTED]> writes:
> I just set up a little test database and i asked myself why this
> pg_xlog-directory has already 33MBs and is still growing.
Because the xlog is allocated in units of 16Mb. If you're talking
about a low-traffic database, the xlog probably won't get la
Is there any way to prevent superuser to acces the
database ?
I mean something like "GRANT /
REVOKE CONNECT" MECHANISM
I have no idea how to prevent root from access data
in one of this ways :
root @ linux:~#su
- postgres
postgres @
linux:/usr/local/pgsql/bin$pg_dump
or
e
I read your response and grinned sheepishly - I should have known that
because I've run across the same situation before. :)
I've installed all the RPMs and everything seems to be working fine.
Thanks.
Lamar Owen wrote:
On Friday 18 October 2002 11:02 am, jburski wrote:
I've just installed
26 matches
Mail list logo
